4 ms·
It's not fair to call Dynamic Allow-Origin simple. This is super tricky and nonstandard usage that is only necessary to workaround the fact that browsers do no
by politician 7y ago
It's not fair to call Dynamic Allow-Origin simple. This is super tricky and nonstandard usage that is only necessary to workaround the fact that browsers do not support multiple values on the Allow-Origin header even though the spec allows it.
That said, yes, when you want to allow multiple origins, reflecting the Origin request header in the Allow-Origin response header is the only solution that works. (Note however, that sometimes the Origin header is not present, an additional difficulty.)
- blackflame7000 7y agoRealistically, Dynamic Allow-Origin is the only way when you want to add more than a few allowed Origins. You wouldn't want to send back a 10kb header detailing all the clients of your service, would you?
- politician 7y agoCall it a bug in the spec if you want, but regardless the spec provides no guidance about whether reflecting the Origin is a good workaround.
- blackflame7000 7y agoYou shouldn’t reflect the origin unless it matches your whitelist. If you wanted to allow all you would just use *. If its not allowed you should return invalid headers instead. Thats why its dynamic
- jonstaab 7y agoThe single-value constraint seems like a feature rather than a bug; if you included your full list of whitelisted domains every time, not only would your HTTP header size be unnecessarily heavy, but you'd be leaking private details about who else is using your service. This isn't an inherent problem, but it could give an attacker some ideas of who to target.
- politician 7y agoMaybe, but the CORS spec says otherwise. https://www.w3.org/TR/cors/#access-control-allow-origin-response-header https://www.w3.org/TR/cors/#access-control-allow-origin-resp... See the note.
- jonstaab 7y agoInteresting that the spec disagrees with the implementation. Maybe the multi-origin leakage was filed as a bug somewhere and fixed post-spec?