Timeline for Origin header reflected in ACAO header with ACAC set to true on an API
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 17, 2021 at 7:08 | comment | added | CBHacking | @RespectableMan1337 Correct, assuming that you don't also use cookies for auth (or things like trusting specific IPs / subnets implicitly). I've seen systems that are nominally using bearer auth, but in practice they also set the token in a cookie, and will accept the token either in the header or in a cookie. That is at risk of CSRF and CORS attacks. But as long as the server requires something that the attacker doesn't know (e.g. auth token) and that the browser doesn't send automatically (i.e. not a cookie), you're fine. | |
| Nov 15, 2021 at 21:50 | vote | accept | RespectableMan1337 | ||
| Nov 15, 2021 at 21:40 | comment | added | RespectableMan1337 | Thanks for the info, that answers my question for the most part. Yes, I do mean it was reflecting arbitrary origins, not only trusted ones. Should have been more specific about the wording as I meant 'Bearer token' instead of 'Authorization token'. For a bit more context, in the preflight request the application also mirrored the Origin header from the request in the ACAO header with ACAC set to true. But it seems the fact that they are using a Bearer token is mitigating their risk as it wont be sent by the browser automatically. | |
| Nov 14, 2021 at 1:22 | history | answered | CBHacking | CC BY-SA 4.0 |