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.