Content Security Policy (CSP): An Allowlist for Browser Resources
Content Security Policy is an allowlist you send to the browser, dictating which scripts, styles, and images are safe to load. It's a primary defense against XSS attacks by blocking unauthorized resources.
Why it exists
By default, a web browser will trust and load any resource a page requests, including scripts. If an attacker can inject a malicious script tag into your page (a Cross-Site Scripting or XSS attack), the browser will execute it. CSP was created to give site owners a way to tell the browser which sources are legitimate, preventing it from loading and running malicious assets.
The mental model
Think of CSP as a bouncer for your website, standing at the browser's door. You, the site owner, provide the bouncer with a strict guest list via the Content-Security-Policy HTTP header. When the browser tries to load a script, image, or stylesheet, the bouncer checks its origin against the list. If the source isn't on the list, it's denied entry and the resource is blocked.
How it works
CSP works by sending a special HTTP response header from your server to the user's browser. This header, Content-Security-Policy, contains a string of directives separated by semicolons. Each directive specifies a policy for a certain type of resource. For example, script-src controls JavaScript files, img-src controls images, and style-src controls CSS. A default-src directive acts as a fallback for any resource type you don't explicitly define a policy for.
When to use it
Use CSP as a critical, defense-in-depth layer against XSS attacks. It's essential for any application that displays user-generated content or handles sensitive data. You can also use specific directives to mitigate other attacks. For instance, the frame-ancestors directive prevents other sites from embedding your page in an iframe, which is the primary defense against clickjacking.
When not to use it
Avoid enforcing a strict CSP on a large, legacy application without thorough testing. If the site relies heavily on inline scripts or has many unvetted third-party dependencies, a restrictive policy will likely break functionality. In these cases, start with the Content-Security-Policy-Report-Only header. This allows the browser to report violations to a specified endpoint without actually blocking them, giving you data to refine your policy before enforcing it.
One canonical example
A common policy for a modern website might be: Content-Security-Policy: default-src 'self'; img-src 'self' data: https://images.example.com; script-src 'self' https://analytics.provider.com;. This policy instructs the browser: first, by default, only allow resources from the same origin ('self'). Second, for images, also allow them from our CDN at images.example.com and from data: URIs. Third, for scripts, also allow them from our analytics provider. All other resources from all other origins will be blocked.
Interview question
What is the core mechanism by which Content Security Policy (CSP) protects against XSS attacks?
- a.It actively scans the rendered DOM for malicious scripts and removes them before execution.
- b.It sanitizes all user input on the server-side to neutralize malicious payloads.
- c.It defines an allowlist of trusted sources, preventing the browser from loading unauthorized external resources.Correct
- d.It encrypts all client-server communication to prevent data tampering.
Why? this is the answer
CSP acts as an allowlist, instructing the browser to only load resources from specified trusted origins, thereby blocking unauthorized scripts. It does not actively scan or remove scripts from the DOM; it prevents them from being loaded in the first place.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.
See open roles