Include default headers by default in API mode #32484
ActionDispatch's default headers are now moved into their own module that are by default included in both Base and API. This allows API-mode applications to take advantage of the default security headers, as well as providing an easy way to add more.
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.
Please see the contribution instructions for more information.
I'm not sure we want to have the default headers in API mode since most of them are present to be interpreted by browsers, not by API clients
Per #32483, I thought your idea was moving this to a module that can be optionally included in ApplicationController in API applications, not making it a default
@guilleiguaran it was both - as mentioned above I can definitely move it out, but it seemed like a good feature to have. APIs are still vulnerable to these things even if they're only meant to be consumed by API clients, seems like a push toward secure-by-default.
I don't see any benefit in making it a default when most of the security headers we added are specific to give advice/instructions to browsers about how to act in certain circumstances. This is a summary of the headers that we include by default:
"X-Frame-Options" => can be used to indicate whether or not a browser should be allowed to render a page in a , <iframe> or . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites
"X-XSS-Protection" => instructs the XSS Auditor from browsers to not render the site when it detects a reflected XSS attempt.
"X-Content-Type-Options" => prevents browsers from making assumptions about the content type if the site didn't declare the type correctly.
"X-Download-Options" => Prevent auto-opening of files, this only for IE8
"X-Permitted-Cross-Domain-Policies" => This one is specific for Adobe Flash Player/Acrobat
"Referrer-Policy" => This is for browser Referrer header
There are any cases where you want to use those headers in the context of JSON/XML APIs?
We don't know what kind of content people are serving from their APIs. Any one of those headers could apply. Just because one usage of api_only is JSON/XML doesn't mean other content types couldn't be served.
For reference, here's all the stuff github's API responds with:
I really don't see why you wouldn't want this. Is there some kind of downside that I'm not seeing?
Regardless, the feature I actually wanted was for default_headers to even be applied to API controllers, because it was confusing to set them and then not see them applied. If this is an issue, I can just strip down the default headers but still allow them to be configured.