secureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
#3177
Conversation
- add img-src policy for images and gifs - move scriptHash to production only so that unsafe-inline works in firefox
- add `Paul Ebose` to list of contributors
|
@blitzjs/next: 11.1.0-0.45.3
When I installed the Also, data URI images failed to load in Firefox due to security restrictions. d7ea7e7
|
| return `default-src 'self'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' data: fonts.gstatic.com; script-src 'self' ${ | ||
| process.env.NODE_ENV === "production" ? "" : "'unsafe-eval'" | ||
| } ${scriptHash}` | ||
| return `default-src 'self'; img-src 'self' res.cloudinary.com data:; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' data: fonts.gstatic.com; script-src 'self' ${ |
There was a problem hiding this comment.
Is this addition necessary? Not every app requires cloudinary, and allowing the data: protocol gives a malicious user a method to inject XSS attacks https://www.w3.org/TR/CSP3/#csp-directives
There was a problem hiding this comment.
Not every app requires cloudinary
It can be removed. I put it in there as an example, since also not every app require Google fonts.
allowing the data: protocol gives a malicious user a method to inject XSS attacks https://www.w3.org/TR/CSP3/#csp-directives
I'm adding data: protocol to the img-src directive. From the link you sent:
To mitigate the risk of cross-site scripting attacks, web developers SHOULD include directives that regulate sources of script and plugins. They can do so by including:
• Both the [script-src](https://www.w3.org/TR/CSP3/#script-src) and [object-src](https://www.w3.org/TR/CSP3/#object-src) directives, or
• a [default-src](https://www.w3.org/TR/CSP3/#default-src) directiveThis web.dev article hints that the script-src, object-src, and base-uri directives are relevant for XSS
There was a problem hiding this comment.
I'm fine with keeping the data: protocol for img-src then, but I think cloudinary can be left out. Unlike cloudinary, Google fonts is used by the default app template and the secureheaders recipe should generate a policy that doesn't produce errors on a fresh blitz app.
It would be a good idea to add a comment next to that line letting users know they can remove the Google font if they've replaced the default CSS though.
- add comment to remove Google fonts domains, if need be
- update recipe repo link - add more helpful links in readme
beerose
changed the title
secureheaders recipesecureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
itsdillon
changed the title
secureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Securitysecureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
itsdillon
changed the title
secureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Securitysecureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
itsdillon
changed the title
secureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Securitysecureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
beerose
changed the title
secureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Securitysecureheaders recipe: add Content-Security-Policy header and includeSubDomains; preload to Strict-Transport-Security
|
Closing since required headers added in #3813 |
Related: #2019
What are the changes and their implications?
Bug Checklist
Feature Checklist
canarybranch)