You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,6 +125,29 @@ end
125
125
126
126
However, I would consider these headers anyways depending on your load and bandwidth requirements.
127
127
128
+
## Disabling secure_headers
129
+
130
+
If you want to disable `secure_headers` entirely (e.g., for specific environments or deployment scenarios), you can use `Configuration.disable!`:
131
+
132
+
```ruby
133
+
ifENV["ENABLE_STRICT_HEADERS"]
134
+
SecureHeaders::Configuration.default do |config|
135
+
# your configuration here
136
+
end
137
+
else
138
+
SecureHeaders::Configuration.disable!
139
+
end
140
+
```
141
+
142
+
**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`.
143
+
144
+
When disabled, no security headers will be set by the gem. This is useful when:
145
+
- You're gradually rolling out secure_headers across different customers or deployments
146
+
- You need to migrate existing custom headers to secure_headers
147
+
- You want environment-specific control over security headers
148
+
149
+
Note: When `disable!` is used, you don't need to configure a default configuration. The gem will not raise a `NotYetConfiguredError`.
150
+
128
151
## Acknowledgements
129
152
130
153
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.
0 commit comments