Guide
Cookies, CSRF, XSS and Privacy Consent Basics
How cookies relate to CSRF and XSS attacks, plus a general, non-legal overview of consent ideas under GDPR, ePrivacy and India's DPDP Act.
Key takeaways
- CSRF abuses the browser attaching cookies automatically; XSS runs attacker script inside your page. They need separate defences.
- MDN lists CSRF tokens, Fetch metadata checks and SameSite as defences; never change state on a GET request.
- HttpOnly stops script from reading a cookie, but injected script can still send authenticated requests.
- Anti-forgery tokens do not survive an XSS flaw, because injected script can read the token.
- Consent and privacy rules are legal questions that differ by place; this guide is general orientation, not legal advice.
Two attacks that involve cookies
Cookies are credentials in disguise, so any attack that borrows or abuses them is serious. Two classic web attacks are closely tied to cookie behaviour: cross-site request forgery and cross-site scripting. They are different problems with different fixes, and confusing them leads to weak defences. This guide explains each in plain terms, then turns to the privacy side of cookies in general terms.
What is cross-site request forgery?
CSRF exploits the fact that a browser attaches cookies automatically. Imagine a user is logged in to a banking site. They visit a malicious page which contains a hidden form that posts to the bank. The browser sends the request along with the bank's session cookie, and the bank, seeing a valid session, may carry out the action. The attacker never learns the cookie. They only trick the browser into using it.
Defences work in layers.
- Set SameSite to Lax or Strict on session cookies, so the browser withholds them from most cross-site requests.
- Use anti-forgery tokens: a random value embedded in the form or sent in a custom header, which the server compares with a copy tied to the session. A different site cannot read it.
- Check the Origin or Referer header on state-changing requests, and reject unexpected values. MDN also describes Fetch metadata headers such as Sec-Fetch-Site, which tell the server whether a request is same-origin, same-site, cross-site or user-initiated.
- Never change state on GET requests, because Lax still lets top-level GET navigations carry the cookie.
- For sensitive actions, ask the user to re-enter a password or confirm in another way.
What is cross-site scripting?
XSS happens when an attacker gets their own script to run in your page, usually because the application includes untrusted input in the page without proper encoding. Once script runs, it acts with the full power of your site in that browser. It can read page content, make authenticated requests and modify what the user sees.
Cookies enter the picture in two ways. First, a script can read any cookie that lacks HttpOnly, and send it to the attacker. Marking session cookies HttpOnly prevents that specific theft. Second, even with HttpOnly, the script can still send requests that include the cookie, so the attacker can act as the user for as long as the page is open. HttpOnly is therefore a damage limiter. The proper fix is to prevent injection: encode output for its context, avoid inserting untrusted data as raw markup, apply a strict content security policy, and keep libraries current.
CSRF and XSS compared
| Aspect | CSRF | XSS |
|---|---|---|
| What the attacker abuses | The browser attaching cookies automatically | Injected script running in your page |
| Can the attacker read the cookie? | No | Yes, unless it is HttpOnly |
| Main cookie-level defence | SameSite plus anti-forgery tokens | HttpOnly (limits theft only) |
| Real fix | Verify where state-changing requests come from | Prevent injection: encode output, set a content security policy |
How do CSRF and XSS relate?
A site with an XSS flaw cannot be saved by anti-forgery tokens, because injected script can read the token from the page. And a site with perfect XSS defences can still suffer CSRF if cookies are sent on every cross-site request. Treat the two as separate checklists, and review both whenever you design authentication.
How do cookies relate to privacy and consent?
Cookies are not only a security topic. They can store identifiers that relate to a person, and that brings privacy rules into view. The remainder of this guide is general information to help developers know which questions to ask. It is not legal advice. Laws differ by country, change over time, and depend on facts specific to each site. Verify your obligations with official sources and with qualified legal counsel.
GDPR and ePrivacy in general terms
In the European Union, two bodies of law are usually discussed together. The General Data Protection Regulation deals with the processing of personal data and sets principles such as transparency, purpose limitation and data minimisation. The ePrivacy rules, implemented through national laws, deal specifically with storing information on, or reading information from, a user's device, which is what cookies do. In general terms, these rules distinguish between cookies that are strictly necessary for a service the user requested, which are treated differently, and other cookies, such as many analytics or advertising cookies, for which consent is commonly expected. Regulators and courts have commented on what valid consent looks like, so how you word and design a banner matters.
India's DPDP Act in general terms
India's Digital Personal Data Protection Act, 2023, governs the processing of digital personal data and centres on notice, consent for specified purposes, and obligations for those who decide why and how data is processed. Its rules and timelines for coming into force have been issued in stages. Developers building for users in India should read the Act and the current rules from official government sources, rather than relying on summaries, and should confirm how it applies to cookie-based identifiers in their particular case.
Practical questions for your team
- Which cookies does your site set, including those set by embedded third-party services? Keep an inventory with name, purpose, lifetime and owner.
- Which are needed to deliver the service the user asked for, and which serve other purposes?
- Can non-essential cookies be kept off until the user makes a choice, and can the user change that choice later as easily as they made it?
- Does your privacy notice describe the cookies in clear language?
- Do your scripts and tags respect the choice, rather than loading before the decision is recorded?
Closing thoughts
Good security and good privacy practice reinforce each other. Fewer cookies, shorter lifetimes, tighter scope and clear documentation reduce both risk and compliance effort. For the legal side, consult official texts and qualified counsel familiar with the places where your users live.
Sources and further reading
- MDN: Cross-site request forgery (CSRF): CSRF tokens, Fetch metadata headers such as Sec-Fetch-Site and SameSite as defence in depth.
- MDN: Cross-site scripting (XSS): the definition of XSS as getting a site to execute malicious code as though it were part of the site.
- MDN: Set-Cookie header: each attribute (Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned) and the cookie prefix rules.
Frequently asked questions
Does the SameSite attribute remove the need for CSRF tokens?
Not entirely. It greatly reduces risk in browsers that enforce it, but it does not cover same-site attacker-influenced requests or older clients, so sensitive actions should still use anti-forgery checks.
If a cookie is HttpOnly, am I safe from XSS?
No. HttpOnly only stops scripts from reading the cookie. Injected script can still send authenticated requests, so you must prevent injection itself.
Do all cookies need consent?
This is a legal question that varies by place and purpose, so this site cannot answer it. In general terms, rules often treat strictly necessary cookies differently from others, but check official sources and consult qualified counsel.
Where should I read about the DPDP Act?
Use the official government publications of India for the Act and its rules, and ask a qualified lawyer how they apply to your service. This guide gives general orientation only.