The HTTP Seal: the Line that Decides Who Enters the Page
In 2011 Mozilla shipped a new header line: X-Content-Security-Policy. A list written on the page's threshold, not a firewall.
In March 2011, with Firefox 4, Mozilla shipped a new line in the HTTP response header: X-Content-Security-Policy. It was not yet a standard. It was a prototype. Brandon Sterne and Sid Stamm had built it from an idea discussed at least since 2007, between Gervase Markham and the researcher Robert Hansen: let a page declare, in the open, from which origins the browser may load scripts, images, frames, connections.
In June 2009 Mozilla had already described the problem in a well-known post: XSS works because everything that arrives in the server response is treated with the same privilege. An injected script and a legitimate script share the same context. Content Security Policy, in that draft, imposed two simple rules: JavaScript had to live in external files, and those files had to come from explicitly approved hosts. The rest — inline scripts, javascript: URIs, event-handler attributes — was to be ignored.
The written threshold
In November 2011 the W3C published the first Working Draft of Content Security Policy 1.0. The syntax was already different from Firefox's experimental one. A year later, in November 2012, the specification reached Candidate Recommendation. Chrome had shipped a prefixed implementation in August 2011; with Chrome 25 it adopted the unprefixed header. Firefox 23, in June 2013, did the same: from X-Content-Security-Policy to Content-Security-Policy.
Here myth touches the object and stops. The object is not an algorithm, not a firewall, not a compliance badge. It is a line. A list. A roster of allowed origins, sent with the page, which the browser reads before loading anything else. The threshold is not in the basement of the data centre: it is in the response itself, stamped above the document like a seal.
What is not on the list
The most quoted benefit remains the original one: if the policy refuses inline scripts, most classic XSS injections stop working even when an escape bug is still there. It is not magic. It is an explicit refusal. The browser does not guess who is trusted: it reads the list. What is not written does not enter.
It is the same grammar that, in another register, I call operational habit. In the essay Security as an Operating Habit I write that good security is not born of anxiety; it is born of clear procedures before the emergency. A CSP is one of those procedures: it does not protect because it is sophisticated, it protects because it is declared in advance, and because the browser applies it without asking for excuses.
On the site I keep a Content Security Policy generator and a security headers checker: not because a line is enough, but because without that line the rest of the discipline stays blind. The page that does not say who may enter lets in anyone who looks as if they belong to the response. The seal is not an ornament. It is the only threshold the browser still recognises as such.
Sources: Mozilla Security Blog, "Content Security Policy 1.0 Lands In Firefox", 11 June 2013; Mozilla Security Blog, "Shutting Down XSS with Content Security Policy", 19 June 2009; W3C, Content Security Policy 1.0 (Working Group Note, 19 February 2015); Wikipedia, Content Security Policy (accessed 5 November 2026).
> ln -s ./linked-nodes
- [PART OF] Operational Cyberinfrastructure
- [RELATED] CSP Generator
- [RELATED] Security as an Operating Habit