cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
Online SRI Hash Generator
Content Security Policy
Whilst the main attraction to CSP is mitigating Cross-Site Scripting attacks, it has a lot more to offer. Here are just a few of the things that you can do with CSP:
- Detect mixed-content
- Control where forms can post data
- Restrict loading of any content type
- Automatically fix mixed-content
- Control nested browsing contexts
- Defend against click-jacking
For example, a common way to steal logins using CSS is by sending a request for a background image or font to an evil URL such as
ais the letter you typed into the password login field. When you would type the next letter of your password, the evil CSS script would send another request but with that letter instead of
a. The evil site then logs these requests to determine your username & password. By allowing unsafe-inline for our style-src, someone could inject this evil code. Fortunately, their code wouldn’t work since our CSP doesn’t allow img-src & font-src from the evil example site.
You are also not in bad company by doing this. A lot of sites, including GitHub & security professional Troy Hunt’s blog use unsafe-inline. Facebook uses unsafe-eval & even requires it for some of their SDKs. Anyone using Google Tag Manager for analytics will also have to reduce their CSP security. I must confess as well. I use GatsbyJS for my personal blog & there are issues that need to be fixed before I can remove unsafe-inline.