Content Security Policy (CSP) in Cybersecurity - Full Explanation

Introduction

Websites often face risks from harmful scripts or content that can steal information or damage the site. Content Security Policy helps stop these risks by controlling what content a website can load and run.

Explanation

Purpose of CSP

CSP is designed to protect websites from attacks like cross-site scripting by specifying which sources of content are allowed. It acts as a set of rules that browsers follow to block unsafe content.

CSP helps prevent harmful content from running on a website by restricting allowed sources.

How CSP Works

Website owners add a CSP header or tag that lists trusted sources for scripts, images, styles, and more. When a browser loads the site, it checks this policy and blocks anything not on the list.

Browsers enforce CSP by blocking content not explicitly allowed by the website's policy.

Common CSP Directives

Directives are rules in CSP that control different content types, like 'script-src' for scripts or 'img-src' for images. Each directive lists allowed sources such as specific domains or 'self' for the same site.

Directives specify which types of content can load and from where.

Benefits of Using CSP

CSP reduces the risk of attacks by limiting what content can run, helping protect user data and site integrity. It also helps detect and report violations to improve security over time.

CSP strengthens website security by controlling content sources and reporting issues.

Limitations of CSP

CSP is not a complete solution and must be carefully configured to avoid blocking needed content. Some older browsers may not fully support CSP, and attackers can still find ways around weak policies.

CSP must be well-configured and combined with other security measures for best protection.

Real World Analogy

Imagine a nightclub that only lets in guests on a special list. The bouncer checks each person and stops anyone not approved from entering. This keeps the club safe from troublemakers.

Purpose of CSP → The nightclub's goal to keep only safe guests inside.

How CSP Works → The bouncer checking the guest list before allowing entry.

Common CSP Directives → Different guest lists for VIPs, staff, and performers.

Benefits of Using CSP → A safer club environment with fewer problems.

Limitations of CSP → Sometimes the bouncer might miss someone or block a real guest by mistake.

Diagram

Diagram

┌─────────────────────────────┐
│       Website Server         │
│  Sends CSP Policy to Browser │
└─────────────┬───────────────┘
              │
              │
┌─────────────▼───────────────┐
│          Browser            │
│  Receives CSP Policy Header │
│  Checks Content Sources     │
│  Blocks Unapproved Content  │
└─────────────┬───────────────┘
              │
              ▼
      Safe Content Displayed

Diagram showing how the website sends a CSP policy to the browser, which then blocks unapproved content before displaying the page.

Key Facts

Content Security Policy (CSP) → A security standard that controls which content sources a website can load and execute.

Directive → A rule in CSP that specifies allowed sources for a particular type of content.

script-src → A CSP directive that controls which script sources are allowed to run.

'self' → A keyword in CSP meaning content can be loaded from the same origin as the website.

Violation Report → A message sent by the browser when content is blocked due to CSP rules.

Common Confusions

CSP blocks all scripts by default.

CSP blocks all scripts by default. CSP only blocks scripts not allowed by its directives; scripts from allowed sources run normally.

CSP protects against all web attacks.

CSP protects against all web attacks. CSP mainly helps prevent content injection attacks but should be combined with other security measures.

Using 'unsafe-inline' in CSP is safe.

Using 'unsafe-inline' in CSP is safe. 'unsafe-inline' allows inline scripts and weakens CSP protection, so it should be avoided when possible.

Summary

Content Security Policy helps websites block harmful content by specifying trusted sources.

It works through directives that tell browsers what content is allowed to load and run.

While powerful, CSP must be carefully set up and used with other security tools for best results.

Practice

1. What is the main purpose of Content Security Policy (CSP) on a website?

easy

A. To store user passwords securely

B. To speed up the website loading time

C. To change the website's layout and design

D. To control which content the website is allowed to load

Solution

1. Step 1: Understand CSP's role in security

   CSP is designed to restrict what content (like scripts, images) a website can load to prevent harmful content.

2. Step 2: Compare options with CSP purpose

   Only controlling content loading matches CSP's main goal; speeding up or design changes are unrelated.

3. Final Answer:

   To control which content the website is allowed to load -> Option D

4. Quick Check:

   CSP controls content loading = A [OK]

Hint: CSP controls content loading to block harmful scripts [OK]

Common Mistakes:

• Confusing CSP with website speed optimization
• Thinking CSP manages website design
• Assuming CSP stores user data

2. Which HTTP header is used to set a Content Security Policy?

easy

A. X-Content-Type-Options

B. Content-Security-Policy

C. Strict-Transport-Security

D. Cache-Control

Solution

1. Step 1: Identify CSP header name

   The official header to set CSP rules is named Content-Security-Policy.

2. Step 2: Eliminate unrelated headers

   X-Content-Type-Options controls MIME sniffing, Strict-Transport-Security enforces HTTPS, and Cache-Control manages caching, none set CSP.

3. Final Answer:

   Content-Security-Policy -> Option B

4. Quick Check:

   CSP header = Content-Security-Policy [OK]

Hint: CSP header is exactly 'Content-Security-Policy' [OK]

Common Mistakes:

• Confusing CSP header with security headers like HSTS
• Using Cache-Control as CSP header
• Mixing up header names with similar security headers

3. Given this CSP directive:
Content-Security-Policy: script-src 'self' https://trusted.com;
Which script source is allowed to run on the website?

medium

A. Scripts only from https://trusted.com

B. Scripts from any website

C. Only scripts from the website itself and https://trusted.com

D. No scripts are allowed

Solution

1. Step 1: Understand the directive meaning

   The directive script-src 'self' https://trusted.com; means scripts can load from the same origin ('self') and from https://trusted.com.

2. Step 2: Analyze options against directive

   Only scripts from the website itself and https://trusted.com correctly states scripts allowed from the website itself and trusted.com; others are incorrect or too broad.

3. Final Answer:

   Only scripts from the website itself and https://trusted.com -> Option C

4. Quick Check:

   script-src 'self' + trusted.com = A [OK]

Hint: 'self' means own site; listed URLs are allowed too [OK]

Common Mistakes:

• Assuming all external scripts are allowed
• Ignoring the 'self' keyword meaning
• Thinking no scripts are allowed due to strictness

4. A website sets this CSP header:
Content-Security-Policy: default-src 'none'; img-src https://images.com;
Why might images from the website itself not load?

medium

A. Because default-src 'none' blocks all sources except those explicitly allowed

B. Because img-src allows images from all sources

C. Because the header syntax is incorrect

D. Because images are blocked by browser settings

Solution

1. Step 1: Understand default-src 'none'

   The directive default-src 'none' blocks all content sources unless specifically allowed.

2. Step 2: Analyze img-src directive

   Only images from https://images.com are allowed; images from the website itself are not allowed because 'self' is not included.

3. Final Answer:

   Because default-src 'none' blocks all sources except those explicitly allowed -> Option A

4. Quick Check:

   default-src 'none' blocks all except allowed = D [OK]

Hint: default-src 'none' blocks all except listed sources [OK]

Common Mistakes:

• Assuming img-src allows all images by default
• Thinking header syntax is wrong without checking directives
• Blaming browser settings instead of CSP rules

5. You want to allow scripts only from your own site and block inline scripts to prevent XSS attacks. Which CSP directive correctly achieves this?

hard

A. Content-Security-Policy: script-src 'self';

B. Content-Security-Policy: script-src 'self' 'unsafe-inline';

C. Content-Security-Policy: script-src *;

D. Content-Security-Policy: default-src 'none'; script-src 'unsafe-inline';

Solution

1. Step 1: Understand blocking inline scripts

   To block inline scripts, do not include 'unsafe-inline' in the script-src directive.

2. Step 2: Analyze options for script sources

   Content-Security-Policy: script-src 'self'; allows scripts only from the website itself ('self') and blocks inline scripts by omission of 'unsafe-inline'. Content-Security-Policy: script-src 'self' 'unsafe-inline'; allows inline scripts, C allows all scripts, and D allows inline scripts but blocks others.

3. Final Answer:

   Content-Security-Policy: script-src 'self'; -> Option A

4. Quick Check:

   Allow 'self' only, no 'unsafe-inline' = B [OK]

Hint: Exclude 'unsafe-inline' to block inline scripts [OK]

Common Mistakes:

• Including 'unsafe-inline' which allows inline scripts
• Using wildcard * which allows all scripts
• Misunderstanding default-src vs script-src directives