 |
VOOZH | about |
|
VOOZH | about |
The author selected the Free Software Foundation to receive a donation as part of the Write for DOnations program.
When the browser loads a page, it executes a lot of code to render the content. The code could be from the same origin as the root document, or a different origin. By default, the browser does not distinguish between the two and executes any code requested by a page regardless of the source. Attackers use this exploit to maliciously inject scripts to the page, which are then executed because the browser has no way of determining if the content is harmful. These situations are where a Content Security Policy (CSP) can provide protection.
A CSP is an HTTP header that provides an extra layer of security against code-injection attacks, such as cross-site scripting (XSS), clickjacking, and other similar exploits. It facilitates the creation of an “allowlist” of trusted content and blocks the execution of code from sources not present in the allowlist. It also reports any policy violations to a URL of your choice, so that you can keep abreast of potential security attacks.
With the CSP header, you can specify approved sources for content on your site that the browser can load. Any code that is not from the approved sources, will be blocked from executing, which makes it considerably more difficult for an attacker to inject content and siphon data.
In this tutorial, you’ll review the different protections the CSP header offers by implementing one in an example Node.js application. You’ll also collect JSON reports of CSP violations to catch problems and fix exploits quickly.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Former Senior Technical Editor at DigitalOcean, with a strong focus on DevOps and System Administration content. Areas of expertise include Terraform, PyTorch, Python, and Django.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
The page is not updating unless clearing the cookies and data
all the specified directives are assigned the ‘self’ keyword in their source list. This indicates that only resources from the current host (including the URL scheme and port number) should be allowed to execute
It’s not true. On the HTTP-pages, ‘self’ covers the http:, ws:, https: and wss: schemes. On the HTTPS:-pages it covers the https: and wss:.
default-src defines a fallback policy for certain directives if they are not explicitly specified in the header.
It’s common misconception. The worker-src directive is not explicitly specified in the CSP been example, but it will not fallback to default-src, you can check it.
Report-To: {“group”:“csp-endpoint”,“max_age”:10886400,“endpoints”:[{“url”:“http://your_server_ip:5500/__ cspreport __”}],“include_subdomains”:true} Be sure to replace the <your_server_ip> placeholder in the Report-To header with your actual server IP address:
URL http://your_server_ip:5500/__cspreport__ is wrong, because Report-To works in secure context only.
In http://your_server_ip construсt the only 127.0.0.1 (or localhost) have a secure context with insecure http:, other IPs can not be used since SSL-certs are not assigned to IPs.
And Report-To fails to work if site is proxied via Cloudflare (CF is screw up the HTTP header).
app.post(‘/__ cspreport __’, (req, res) => { console.log(req.body); });
This is an example of incorrect handling of violation reports. This code doesn’t return the correct status code and after submitting the violation report the browser keeps hanging awaiting a response.
It need to finalize code with res.status(204).end().
If the browser supports the report-to directive, the payload should have a similar structure to what is following. Notice how it’s different from the report-uri payload while still carrying the same information:
Incorrect example is shown, other field names do send.
The highlighted section here is the exact SHA256 hash that you would need to add to the script-src directive to allow the execution of the specific inline script that triggered the violation.
It doesn’t always work, there is a lot of topics on SO like CSP header fails with “Refused to apply inline style…” but I have already added the hash
It is 2015 level article, nothing about tokens: 'report-sample', 'strict-dynamic', 'unsafe-hashes', 'none', 'unsafe-allow-redirects’, 'unsafe-eval' and * special character. Nothing about usage of non-network scheme-sources like data:, blob:, filesystem:.
Life has gone far ahead, a new concept of XSS protection via Trusted Types API is now implemented in CSP, but you still create tutorials how to work the CSP1 with using the one of most problematic and badly supported CSP3 directive.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Scale up as you grow — whether you're running one virtual machine or ten thousand.
