Bird
Raised Fist0
Cybersecurityknowledge~30 mins

Content Security Policy (CSP) in Cybersecurity - Mini Project: Build & Apply

Choose your learning style10 modes available
LearnWhyDeepVisualPracticeChallengeProjectRecallTime

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Content Security Policy (CSP) Setup for a Website
📖 Scenario: You are a web developer tasked with improving the security of a website by adding a Content Security Policy (CSP). CSP helps prevent attacks like cross-site scripting by controlling which resources the browser is allowed to load.In this project, you will create a simple HTML page and add a CSP header to it step-by-step.
🎯 Goal: Build a basic HTML page with a Content Security Policy that only allows scripts and styles from the same origin and blocks inline scripts.
📋 What You'll Learn
Create a basic HTML5 page structure
Add a meta tag for Content Security Policy
Configure the CSP to allow scripts and styles only from the same origin
Block inline scripts and styles
💡 Why This Matters
🌍 Real World
Content Security Policy is used by web developers and security teams to protect websites from malicious code injection and cross-site scripting attacks.
💼 Career
Understanding and implementing CSP is important for roles in web development, cybersecurity, and IT security to ensure safer web applications.
Progress0 / 4 steps
1
Create a basic HTML5 page
Create a basic HTML5 page with <!DOCTYPE html>, <html>, <head>, and <body> tags. Inside the <head>, add a <title> with the text Secure Page.
Cybersecurity
Hint

Start with the standard HTML5 skeleton and add a title inside the head section.

2
Add a Content Security Policy meta tag
Inside the <head> tag, add a <meta> tag with http-equiv="Content-Security-Policy" and an empty content attribute for now.
Cybersecurity
Hint

Use a meta tag with http-equiv set to Content-Security-Policy and leave the content empty for now.

3
Configure CSP to allow scripts and styles only from the same origin
Set the content attribute of the CSP meta tag to allow scripts and styles only from the same origin using script-src 'self'; style-src 'self';.
Cybersecurity
Hint

Use script-src 'self'; style-src 'self'; inside the content attribute to restrict scripts and styles to the same origin.

4
Block inline scripts and styles in CSP
Update the content attribute of the CSP meta tag to also block inline scripts and styles by not including 'unsafe-inline'. The final content should be script-src 'self'; style-src 'self'; which already blocks inline code.
Cybersecurity
Hint

By not adding 'unsafe-inline', inline scripts and styles are blocked by default.

Practice

(1/5)
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