Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add always condition to security Header directives #186

Closed
LeoColomb opened this issue Mar 26, 2019 · 2 comments
Closed

Add always condition to security Header directives #186

LeoColomb opened this issue Mar 26, 2019 · 2 comments
Labels
awaiting feedback Further information is requested enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@LeoColomb
Copy link
Member

LeoColomb commented Mar 26, 2019

Following #183, maybe all Header directives in src/security/ are eligible to the always condition.

But the documentation isn't very clear how we should use always, so guessing where to place it is not trivial.

@LeoColomb LeoColomb added enhancement New feature or request awaiting feedback Further information is requested help wanted Extra attention is needed labels Mar 26, 2019
@Malvoz
Copy link
Contributor

Malvoz commented Mar 26, 2019

I'm not too comfortable with Apache docs, but quoting from (and emphasis mine for the always condition):

The optional condition argument determines which internal table of responses headers this directive will operate against: onsuccess (default, can be omitted) or always. The difference between the two lists is that the headers contained in the latter are added to the response even on error, and persisted across internal redirects (for example, ErrorDocument handlers).

You'd most likely want (e.g.) security headers to persist through errors, however you may not want the headers to persist behind redirects. Imagine you are setting a "dynamic" CSP; allowing scripts from a source on one page, but not on another page to which you are redirecting.

The apache docs goes on to say:

Note also that repeating this directive with both conditions makes sense in some scenarios because always is not a superset of onsuccess with respect to existing headers:

  • You're adding a header to a locally generated non-success (non-2xx) response, such as a redirect, in which case only the table corresponding to always is used in the ultimate response.
  • You're modifying or removing a header generated by a CGI script or by mod_proxy_fcgi, in which case the CGI scripts' headers are in the table corresponding to always and not in the default table.
  • You're modifying or removing a header generated by some piece of the server but that header is not being found by the default onsuccess condition.

And this goes over my head. Is it possible to have headers persist through 4xx status codes but not 3xx redirects?

@LeoColomb LeoColomb added this to the v4.0.0 milestone May 6, 2019
@LeoColomb
Copy link
Member Author

Yes, reading this description again, still hard to follow.
One things that afraid me is the following:

  • You're modifying or removing a header generated by a CGI script or by mod_proxy_fcgi, in which case the CGI scripts' headers are in the table corresponding to always and not in the default table.

If I understand well, headers generated by the application (fpm/cgi/etc) will be replaced if we use always. Right?
If so we can't add always version, the application should always take the precedence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Further information is requested enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants