Content Security Policy in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a script violates the CSP in Django?

If a Django app has a Content Security Policy that disallows inline scripts, what will happen if the page tries to run an inline <script> block?

A The inline script runs normally without any warnings or errors.

B The Django server throws an error and stops serving the page.

C The browser blocks the inline script from running and logs a CSP violation in the console.

D The inline script runs but logs a warning on the server side.

💡 Hint

Think about how browsers enforce CSP policies on the client side.

Content Security Policy is enforced by the browser. If an inline script is disallowed, the browser blocks it and logs a violation in the developer console. The server does not throw errors for CSP violations.

📝 Syntax

intermediate

Which Django middleware setting correctly enables CSP with default-src 'self'?

Choose the correct way to add Content Security Policy middleware in Django settings to allow resources only from the same origin.

A

MIDDLEWARE = ['django.middleware.security.SecurityMiddleware', 'csp.middleware.CSPMiddleware']
CSP_DEFAULT_SRC = ("self",)

B

MIDDLEWARE = ['django.middleware.security.SecurityMiddleware', 'csp.middleware.CSPMiddleware']
CSP_DEFAULT_SRC = ("'self'",)

C

MIDDLEWARE = ['django.middleware.security.SecurityMiddleware', 'csp.middleware.CSPMiddleware']
CSP_DEFAULT_SRC = ['self']

D

MIDDLEWARE = ['csp.middleware.CSPMiddleware', 'django.middleware.security.SecurityMiddleware']
CSP_DEFAULT_SRC = ['self']

💡 Hint

Remember the CSP_DEFAULT_SRC value must be a tuple with quotes around 'self'.

The CSP middleware must be added after SecurityMiddleware. The CSP_DEFAULT_SRC must be a tuple with the string "'self'" including quotes, so the browser understands it as the keyword self.

🔧 Debug

advanced

Why does this CSP header cause a browser error?

Given this Django CSP header: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline', why might the browser still block inline scripts?

A Because the CSP header syntax is invalid due to missing semicolons.

B Because the CSP header is missing the <code>style-src</code> directive, which is required for scripts.

C Because 'unsafe-inline' is not a valid CSP keyword and causes the header to be ignored.

D Because the browser requires a nonce or hash for inline scripts even if 'unsafe-inline' is present in some strict modes.

💡 Hint

Consider modern browser security policies and how they treat 'unsafe-inline'.

'unsafe-inline' allows inline scripts but modern browsers may still block inline scripts unless a nonce or hash is provided for better security. This is common in strict CSP enforcement modes.

❓ state_output

advanced

What is the effect of this Django CSP setting on image loading?

If Django settings include CSP_IMG_SRC = ("'self'", 'https://images.example.com'), what images will the browser allow to load?

A Only images from the same origin and from https://images.example.com will load; others are blocked.

B All images will load regardless of source because CSP_IMG_SRC is ignored.

C Only images from https://images.example.com will load; same origin images are blocked.

D No images will load because the syntax is invalid.

💡 Hint

Think about what 'self' means in CSP and how multiple sources work.

'self' means the same origin as the page. Adding https://images.example.com allows images from that domain too. Other sources are blocked by CSP.

🧠 Conceptual

expert

Why is using CSP with nonce better than 'unsafe-inline' in Django?

In Django, why is it more secure to use a nonce-based Content Security Policy for scripts instead of allowing 'unsafe-inline'?

A Nonce-based CSP allows inline scripts only if they have a matching nonce, preventing attackers from injecting scripts without the nonce.

B 'unsafe-inline' is more secure because it allows all inline scripts, making debugging easier.

C Nonce-based CSP disables all scripts, which is safer than allowing any inline scripts.

D 'unsafe-inline' requires a nonce to work, so they are equivalent in security.

💡 Hint

Consider how CSP nonces help prevent cross-site scripting attacks.

Nonce-based CSP only allows inline scripts that have a server-generated nonce attribute matching the CSP header. This blocks injected scripts without the nonce, improving security over 'unsafe-inline' which allows all inline scripts.

Practice

1. What is the main purpose of Content Security Policy (CSP) in a Django application?

easy

A. To handle database migrations automatically

B. To speed up the loading time of the website

C. To control which external resources can be loaded by the browser

D. To manage user authentication and sessions

Solution

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

   CSP is designed to restrict what content the browser can load, preventing harmful scripts or resources.

2. Step 2: Identify the correct purpose among options

   Only To control which external resources can be loaded by the browser describes controlling external resource loading, which matches CSP's function.

3. Final Answer:

   To control which external resources can be loaded by the browser -> Option C

4. Quick Check:

   CSP purpose = control resource loading [OK]

Hint: CSP controls resource loading to improve security [OK]

Common Mistakes:

• Confusing CSP with performance optimization
• Thinking CSP manages user sessions
• Assuming CSP handles database tasks

2. Which of the following is the correct way to add a CSP header in a Django view?

easy

A. response.setHeader('Content-Security-Policy', "default-src 'self'")

B. response['headers']['Content-Security-Policy'] = "default-src 'self'"

C. response.set_header('Content-Security-Policy', "default-src 'self'")

D. response['Content-Security-Policy'] = "default-src 'self'"

Solution

1. Step 1: Recall Django HttpResponse header syntax

   In Django, headers are set by assigning to response['Header-Name'].

2. Step 2: Match the correct syntax

   response['Content-Security-Policy'] = "default-src 'self'" uses response['Content-Security-Policy'] = "default-src 'self'", which is correct Django syntax.

3. Final Answer:

   response['Content-Security-Policy'] = "default-src 'self'" -> Option D

4. Quick Check:

   Django header set = response['Header'] = value [OK]

Hint: Use response['Header-Name'] = value to set headers in Django [OK]

Common Mistakes:

• Using JavaScript or Flask header syntax in Django
• Calling non-existent methods like setHeader
• Trying to set headers via response.headers dictionary

3. Given this Django middleware snippet, what CSP header will be sent in the response?

class CSPMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        response['Content-Security-Policy'] = "script-src 'self' https://cdn.example.com"
        return response

medium

A. Content-Security-Policy: default-src 'self'

B. Content-Security-Policy: script-src 'self' https://cdn.example.com

C. No Content-Security-Policy header is set

D. Content-Security-Policy: script-src 'none'

Solution

1. Step 1: Analyze the middleware code

   The middleware sets response['Content-Security-Policy'] to "script-src 'self' https://cdn.example.com" before returning the response.

2. Step 2: Determine the header sent

   The header sent will exactly match the assigned string in the middleware.

3. Final Answer:

   Content-Security-Policy: script-src 'self' https://cdn.example.com -> Option B

4. Quick Check:

   Middleware sets CSP header = script-src 'self' https://cdn.example.com [OK]

Hint: Middleware sets header exactly as assigned before returning response [OK]

Common Mistakes:

• Assuming default-src is set instead of script-src
• Thinking header is not set because of missing return
• Confusing middleware with view-level headers

4. You added this CSP header in Django but your inline scripts stopped working:

response['Content-Security-Policy'] = "default-src 'self'"

What is the likely cause and fix?

medium

A. Inline scripts blocked; add 'unsafe-inline' to script-src directive

B. Header syntax error; remove quotes around 'self'

C. Missing HTTPS; change 'self' to https://self

D. No fix needed; inline scripts should work by default

Solution

1. Step 1: Understand CSP default-src effect on scripts

   default-src 'self' blocks inline scripts by default because inline scripts are unsafe.

2. Step 2: Fix by allowing inline scripts explicitly

   Adding 'unsafe-inline' to script-src directive allows inline scripts to run.

3. Final Answer:

   Inline scripts blocked; add 'unsafe-inline' to script-src directive -> Option A

4. Quick Check:

   Inline scripts need 'unsafe-inline' in CSP [OK]

Hint: Add 'unsafe-inline' to allow inline scripts in CSP [OK]

Common Mistakes:

• Removing quotes around 'self' breaks CSP syntax
• Changing 'self' to https://self is invalid
• Assuming inline scripts work without explicit permission

5. You want to allow images from your own site and from https://images.example.com but block all other sources. Which CSP header directive is correct in Django?

hard

A. response['Content-Security-Policy'] = "img-src 'self' https://images.example.com; default-src 'none'"

B. response['Content-Security-Policy'] = "default-src 'self' https://images.example.com"

C. response['Content-Security-Policy'] = "img-src *; default-src 'self'"

D. response['Content-Security-Policy'] = "img-src 'none'; default-src https://images.example.com"

Solution

1. Step 1: Identify directives to allow images only from specific sources

   img-src directive controls image sources; 'self' allows own site, plus https://images.example.com.

2. Step 2: Block all other sources by setting default-src to 'none'

   default-src 'none' blocks everything else not explicitly allowed.

3. Final Answer:

   response['Content-Security-Policy'] = "img-src 'self' https://images.example.com; default-src 'none'" -> Option A

4. Quick Check:

   Allow images from self and example.com, block others [OK]

Hint: Use img-src for images and default-src 'none' to block others [OK]

Common Mistakes:

• Using default-src for images allows too many sources
• Using img-src * allows all images, not secure
• Setting img-src 'none' blocks all images