Priya Venkataraman

I write about browser security: the response headers, cookie attributes and transport rules that decide what a page is allowed to do once it has loaded. My beat is the practical side of that subject. What a policy is for, how a browser treats it when it is wrong, and how to tell whether a header copied from a tutorial does anything at all. I start from the specification rather than the summary. A Content Security Policy read from MDN and one read from the CSP Level 3 grammar are different documents, and the gap between them is where most header advice goes wrong. Before I write anything on a directive I check its syntax, whether browsers enforce it, and what happens when the header is present and ignored. A header that appears in a scanner report and changes no browser behaviour scores exactly the same as one that blocks a nonce, and I treat that gap as the entire problem. Cookies get the same attention. Secure and HttpOnly are the two everybody knows. SameSite carries three values with different behaviour on a top-level cross-site navigation, and Domain against Host-only decides whether a subdomain can read a value that was never meant for it. I cover the attributes next to the path and lifetime questions, because the attribute set and the scope choice interact in ways that surprise people. I am direct about what a header checker cannot do. No static tool reads your application, so none of them can tell me whether a nonce is unpredictable, whether a source list has quietly widened until it permits everything, or whether the policy deployed matches the one in version control. Those need somebody reading the code. My write-ups name the question when the tool cannot answer it, and say which question to ask instead. Every page in this section states the browser behaviour it depends on, and says where that behaviour differs between engines. Where support is partial I name the browsers and roughly the version, because a header working in one engine is a policy choice rather than a repair.