I have been researching various techniques for preventing CSRF attacks, such as SOP, SameSite, Secure, Referer validation, and CSRF Tokens, and their potential bypasses. During my research, I discovered the following vulnerabilities:

  1. A website's subdomain or sibling domain is vulnerable to XSS or HTML Injection. For instance:
    • Subdomain: a.com and vulnerable.a.com
    • Sibling: a.a.com and vulnerable.a.com
  2. A subdomain takeover (SDTO) attack
  3. A Man-in-the-middle (MITM) attack

However, I'm unsure if correctly implemented Signed Double Submit Cookie and Referer validation are vulnerable to those?

What I mean by correctly implemented:

  • With Signed Double Submit is meant a session-bound and signed (HMAC) CSRF token, stored in a non-HttpOnly cookie with the Secure flag.
  • With Referer validation is meant a Strict (block requests that have no Referer header) and Strong (handles subdomain and URL queries) Referer validation.


  1. Is Signed Double Submit Cookie & Strict & Strong Referer validation vulnerable to MITM?

    According to this SO answer:

    ... If an application is hosted at https://secure.example.com, even if the cookies are set with the secure flag, a man in the middle can force connections to http://secure.example.com and set (overwrite) any arbitrary cookies (even though the secure flag prevents the attacker from reading those cookies)...

    If I read this correctly, this would mean that a MITM can initiate requests from http://b.com to http://a.com, but make the request look like it came from http://a.com. If that is true, then:

    • Signed Double Submit Cookie is vulnerable. The attacker doesn't even need to overwrite the CSRF cookie, since the original one is passed along automatically
    • Strict & Strong Referer validation is vulnerable. The request, even if made from b.com has the value a.com as the Referer value.
  2. Is Signed Double Submit Cookie vulnerable to a vulnerable subdomain?
    If an attacker gains access to vulnerable.a.com, they can read and write any cookie.

    Is it true that only cookie prefixes prevent such an attack, or am I missing something where the Signed Double Submit Cookie pattern would prevent this?

  3. Is Strict & Strong Referer validation vulnerable to vulnerable subdomain?
    Let's look over some facts:

    • The Referer header is a forbidden header name meaning it cannot be changed programmatically.
    • The session cookie or JWT are commonly protected with the HttpOnly flag, preventing the attacker from reading or writing to it, even on subdomains.

    With that in mind, does this mean that Strict & Strong Referer validation is not vulnerable to vulnerable subdomains?

  4. Is OWASP's recommendation false?
    The Signed Double Submit Cookie pattern is categorized as a mitigation technique. The Strict & Strong Referer validation pattern is only categorized as a Defence in Depth (DiD) technique.

    Depending on the above questions, it may seem that only a combination of a Signed Double Submit Cookie and Strict & Strong Referer validation is a true mitigation technique, while alone both are DiD's?

  • The OWASP tag doesn't apply to this question, and you have no need for special formatting of your question.
    – schroeder
    May 9, 2023 at 14:55
  • @schroeder I would usually agree with the special formatting, but your changes disorganize the indentation, making it more difficult to read what belongs together. I was just using vanilla Markdown to make it more segmented and thereby more readable. Have you looked at the text after bullet point 1 & 2?
    – Advena
    May 9, 2023 at 19:42
  • If you are needing that much formatting and all that supporting material, that might be a sign that you are trying to cram too many independent questions into a single post.
    – schroeder
    May 9, 2023 at 19:53

1 Answer 1


As to 1):

I think you misunderstand the linked paper. What the paragraph says is that naive double-submit cookies can be defeated through a man-in-the-middle attack:

  • Scenario 1: The legitimate application is reachable over HTTPS, and the double-submit cookie has the Secure flag set. However, if the client makes a connection over HTTP, then a man-in-the-middle can overwrite the double-submit cookie (not read the existing one) and thereby defeat the protection.
  • Scenario 2: The application is reachable over HTTPS, the double-submit cookie has the Secure flag set, and the server enforces HTTPS connections for the primary domain (but not subdomains) through HSTS. If the client makes an HTTP connection to a subdomain, then a man-in-the-middle can still overwrite the double-submit cookie (not read it) through this subdomain.

A double submit cookie with a MAC (or “signed cookie” as you call it) and the Secure flag set does not have this issue. Since the attacker can neither read the current Secure cookie nor calculate the MAC for their own token, they cannot do a classical CSRF attack. However, as soon as plaintext HTTP is used, there are of course all kinds of other issues which may make CSRF completely unnecessary. For example, when a client makes an HTTP request to the target website, the attacker could simply show the log-in form in the response and wait for the client to enter their credentials.

As to 2):

An attacker who controls a subdomain can set cookies for all higher-order domains (except for public suffixes) and make them be sent to all corresponding subdomains, but they cannot read arbitrary cookies. This is why double-submit cookies with a MAC are useful. If the legitimate application at a.com stores an anti-CSRF token with a MAC inside a cookie that has no domain set, then this cookie will not be sent to subdomains. The subdomains can try to set their own anti-CSRF token, but since they're not able to create a valid MAC, the token will be rejected by the server.

As to 3):

If the server checks the exact domain of the referrer, then this validation is not vulnerable to subdomain-based attack. However, there are valid reasons for users to disable the referrer (e. g. to enhance privacy), so you cannot assume it's present.

As to 4):

No, the OWASP recommendations are not false. A double-submit cookies with a MAC and the right properties (empty domain, or cookie prefix) is a good solution. Referrer checks are unreliable, since there may not be a referrer at all. At best, this would be a second line of defense in case the referrer is set.

  • As to 1): Thanks, you cleared up some things there. I definitely misread that part because I couldn't find anything on the web that mentions similar.
    – Advena
    May 9, 2023 at 19:46
  • As to 2): I see now. However, it seems then that an attacker does not have to read or set a CSRF Token. They can send any CSRF attacks from the vulnerable subdomain, even with SameSite in place. The original session and CSRF cookie are passed during the request. Only cookie prefixes would fix this issue?
    – Advena
    May 9, 2023 at 19:52
  • As to 3): I strongly agree. On the other hand, I have seen it heavily implemented in the wild (Strict Referer validation). Django's CSRF Middleware uses a combination of session-independent CSRF tokens + Origin validation + Referer validation. It also seemed that when Brave placed noreferrer on all pages, it broke many websites.
    – Advena
    May 9, 2023 at 19:56
  • As to 4): Lovely, thanks for your answer!
    – Advena
    May 9, 2023 at 19:57
  • 1
    To 2): To defeat cookie-based CSRF protection (even the naive variant), an attacker has to know the token, so that they can include it in the request parameters. If they simply create a form and make the victim's browser submit it, yes, the anti-CSRF cookie will be automatically included in the request, but there's no matching parameter. It's only half of the double submission. So the attacker either has to read the existing token or set their own (unless this is prevented with a MAC).
    – Ja1024
    May 9, 2023 at 20:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .