-
Notifications
You must be signed in to change notification settings - Fork 253
Add Configuration.disable! to completely disable secure_headers #568
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
Changes from all commits
d81007d
0502028
4c0e94a
cbbcaad
b93ac8d
8f188da
af7f61b
5ab4183
ccae709
6a78f95
d922c87
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -125,6 +125,29 @@ end | |
|
|
||
| However, I would consider these headers anyways depending on your load and bandwidth requirements. | ||
|
|
||
| ## Disabling secure_headers | ||
|
|
||
| If you want to disable `secure_headers` entirely (e.g., for specific environments or deployment scenarios), you can use `Configuration.disable!`: | ||
|
|
||
| ```ruby | ||
| if ENV["ENABLE_STRICT_HEADERS"] | ||
| SecureHeaders::Configuration.default do |config| | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. since this is a configuration setting, this can only be done at server startup right? I think that's implied but would it be valuable to make that clearer in case someone gets the idea that they could disable this during runtime? I could go either way on whether or not that's overkill
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point. I think that's worth documenting.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've also made it so that they're mutually exclusive preventing one from trying to configure and then disable. |
||
| # your configuration here | ||
| end | ||
| else | ||
| SecureHeaders::Configuration.disable! | ||
| end | ||
| ``` | ||
|
|
||
| **Important**: This configuration must be set during application startup (e.g., in an initializer). Once you call either `Configuration.default` or `Configuration.disable!`, the choice cannot be changed at runtime. Attempting to call `disable!` after `default` (or vice versa) will raise an `AlreadyConfiguredError`. | ||
|
|
||
| When disabled, no security headers will be set by the gem. This is useful when: | ||
| - You're gradually rolling out secure_headers across different customers or deployments | ||
| - You need to migrate existing custom headers to secure_headers | ||
| - You want environment-specific control over security headers | ||
|
|
||
| Note: When `disable!` is used, you don't need to configure a default configuration. The gem will not raise a `NotYetConfiguredError`. | ||
|
|
||
| ## Acknowledgements | ||
|
|
||
| This project originated within the Security team at Twitter. An archived fork from the point of transition is here: https://github.com/twitter-archive/secure_headers. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think this is important enough to be in the README or would it make sense to document it elsewhere?