| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
There is no controller instance when using a redirect route or a
mounted rack application so pass the request object as the context
when resolving dynamic CSP sources in this scenario.
Fixes #34200.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if a dynamic source returned a symbol such as :self it
would be converted to a string implicity, e.g:
policy.default_src -> { :self }
would generate the header:
Content-Security-Policy: default-src self
and now it generates:
Content-Security-Policy: default-src 'self'
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For nonce, only `script-src` and` style-src` are meaningful in the
definition of Content Security Policy Level 2.
https://www.w3.org/TR/CSP2/#script-src-nonce-usage
https://www.w3.org/TR/CSP2/#style-src-nonce-usage
Therefore, I think that customization function not needs and it is enough
to enable both directives inside the framework.
Fixes #32920
|
| |
|
|
|
|
|
| |
Specification: https://w3c.github.io/webappsec-csp/#directive-prefetch-src
This directive can already be used as an experimental feature in Chrome.
Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=801561
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
If the app has the CSP disabled globally allow a controller action
to enable the policy for that request.
|
| |
|
|
|
|
|
|
| |
e.g:
class LegacyPagesController < ApplicationController
content_security_policy false, only: :index
end
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the UJS library creates a script tag to process responses it
normally requires the script-src attribute of the content security
policy to include 'unsafe-inline'.
To work around this we generate a per-request nonce value that is
embedded in a meta tag in a similar fashion to how CSRF protection
embeds its token in a meta tag. The UJS library can then read the
nonce value and set it on the dynamically generated script tag to
enable it to execute without needing 'unsafe-inline' enabled.
Nonce generation isn't 100% safe - if your script tag is including
user generated content in someway then it may be possible to exploit
an XSS vulnerability which can take advantage of the nonce. It is
however an improvement on a blanket permission for inline scripts.
It is also possible to use the nonce within your own script tags by
using `nonce: true` to set the nonce value on the tag, e.g
<%= javascript_tag nonce: true do %>
alert('Hello, World!');
<% end %>
Fixes #31689.
|
| |
|
|
|
|
|
|
|
| |
Although the spec[1] is defined in such a way that a trailing semi-colon
is valid it also doesn't allow a semi-colon by itself to indicate an
empty policy. Therefore it's easier (and valid) just to omit it rather
than to detect whether the policy is empty or not.
[1]: https://www.w3.org/TR/CSP2/#policy-syntax
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 86f7c269073a3a9e6ddec9b957deaa2716f2627d, reversing
changes made to 5ece2e4a4459065b5efd976aebd209bbf0cab89b.
If a policy is set then we should generate it even if it's empty.
However what is happening is that we're accidentally generating an
empty policy when the initializer is commented out by default.
|
| |
|
|
|
|
|
|
| |
`Rails.application.config.content_security_policy` is configured with no
policies by default. In this case, Content-Security-Policy header should
not be generated instead of generating the header with no directives.
Firefox also warns "Content Security Policy: Couldn't process unknown
directive ''".
|
| |
|
| |
Use Object#deep_dup to safely duplicate policy values
|
|
|
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
