What if your website could stop hackers before they even try to break in?
Why Content Security Policy in Django? - Purpose & Use Cases
Start learning this pattern below
Jump into concepts and practice - no test required
Imagine you build a website and want to keep it safe from hackers injecting bad scripts. You try to check every script manually and block suspicious ones yourself.
Manually checking and blocking harmful scripts is slow, easy to miss, and can break your site if you block the wrong things. It's like trying to guard every door and window in a huge house alone.
Content Security Policy (CSP) lets you tell the browser exactly which scripts and resources are safe to load. This automatic guard stops bad code before it runs, keeping your site safe without extra work.
if script_source not in allowed_list: block_script()
Content-Security-Policy: script-src 'self' https://trusted.com;It makes your website safer by automatically blocking harmful content, so you can focus on building features without worrying about attacks.
A news website uses CSP to allow only its own scripts and trusted ad providers, stopping hackers from injecting fake news or stealing user data.
Manual script blocking is slow and error-prone.
CSP tells browsers what is safe to load automatically.
This protects your site from many common attacks easily.
Practice
Solution
Step 1: Understand CSP's role in security
CSP is designed to restrict what content the browser can load, preventing harmful scripts or resources.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.Final Answer:
To control which external resources can be loaded by the browser -> Option CQuick Check:
CSP purpose = control resource loading [OK]
- Confusing CSP with performance optimization
- Thinking CSP manages user sessions
- Assuming CSP handles database tasks
Solution
Step 1: Recall Django HttpResponse header syntax
In Django, headers are set by assigning to response['Header-Name'].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.Final Answer:
response['Content-Security-Policy'] = "default-src 'self'" -> Option DQuick Check:
Django header set = response['Header'] = value [OK]
- Using JavaScript or Flask header syntax in Django
- Calling non-existent methods like setHeader
- Trying to set headers via response.headers dictionary
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 responseSolution
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.Step 2: Determine the header sent
The header sent will exactly match the assigned string in the middleware.Final Answer:
Content-Security-Policy: script-src 'self' https://cdn.example.com -> Option BQuick Check:
Middleware sets CSP header = script-src 'self' https://cdn.example.com [OK]
- Assuming default-src is set instead of script-src
- Thinking header is not set because of missing return
- Confusing middleware with view-level headers
response['Content-Security-Policy'] = "default-src 'self'"What is the likely cause and fix?
Solution
Step 1: Understand CSP default-src effect on scripts
default-src 'self' blocks inline scripts by default because inline scripts are unsafe.Step 2: Fix by allowing inline scripts explicitly
Adding 'unsafe-inline' to script-src directive allows inline scripts to run.Final Answer:
Inline scripts blocked; add 'unsafe-inline' to script-src directive -> Option AQuick Check:
Inline scripts need 'unsafe-inline' in CSP [OK]
- Removing quotes around 'self' breaks CSP syntax
- Changing 'self' to https://self is invalid
- Assuming inline scripts work without explicit permission
Solution
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.Step 2: Block all other sources by setting default-src to 'none'
default-src 'none' blocks everything else not explicitly allowed.Final Answer:
response['Content-Security-Policy'] = "img-src 'self' https://images.example.com; default-src 'none'" -> Option AQuick Check:
Allow images from self and example.com, block others [OK]
- Using default-src for images allows too many sources
- Using img-src * allows all images, not secure
- Setting img-src 'none' blocks all images
