Content Security Policy in Django

Introduction

Content Security Policy (CSP) helps keep your Django website safe by controlling what content can load. It stops bad scripts or files from running.

When you want to stop hackers from injecting harmful scripts into your site.

When you want to control which external resources like images or fonts your site can use.

When you want to improve your site's security by reducing risks of cross-site scripting (XSS).

When you want to report violations of your content rules to monitor attacks.

When you want to make sure only trusted sources provide content to your users.

Syntax

Django

Content-Security-Policy: <directive> <source-list>; <directive> <source-list>; ...

Directives define types of content like scripts, images, styles.

Source lists specify allowed URLs or keywords like 'self' or 'none'.

Examples

This policy allows content only from your own site, images from a specific domain, and blocks all scripts.

Django

Content-Security-Policy: default-src 'self'; img-src https://images.example.com; script-src 'none';

This allows styles from your site and inline styles (needed for some CSS frameworks).

Django

Content-Security-Policy: default-src 'self'; style-src 'self' 'unsafe-inline';

This blocks all content except connections to your site and a trusted API.

Django

Content-Security-Policy: default-src 'none'; connect-src 'self' https://api.example.com;

Sample Program

This Django view sends a simple HTML response with a Content Security Policy header. It allows content only from the same site, images from a trusted domain, and blocks all scripts.

Django

from django.http import HttpResponse

def my_view(request):
    response = HttpResponse("<h1>Hello, secure world!</h1>")
    csp_policy = "default-src 'self'; img-src https://images.example.com; script-src 'none';"
    response['Content-Security-Policy'] = csp_policy
    return response

Important Notes

Always test your CSP carefully to avoid blocking needed content.

You can use browser developer tools to see CSP violations and fix them.

Use 'report-uri' or 'report-to' directives to get reports about policy violations.

Summary

CSP helps protect your Django site by controlling what content loads.

Set CSP headers in your views or middleware to enforce rules.

Use clear directives and test to keep your site secure and working well.

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