Use subresource integrity
User guide
- Getting Started
Api
Concepts
Configurations
Configuring webhint
Connectors
Development flow integration
Extensions
Formatters
Hints
- Avoid CSS limits
- Avoid HTTP redirects
- axe accessibility check
- Babel configuration hint set
- Compatibility of CSS, HTML and JavaScript features
- Correct `Content-Type` header
- Correct manifest extension
- Correct viewport
- Detect CSS Reflows
- Disallowed HTTP headers
- External links disown opener
- Has web app manifest
- Highest document mode
- HTTP cache
- Leading '.' in `classList.add` or `classList.remove`
- Manifest has name
- Minify JavaScript
- Modern DOCTYPE
- No `createElement` with SVG
- No `P3P` headers
- No broken links
- No byte-order mark
- No Inline CSS Styles
- No protocol-relative URLs
- No small error pages
- No vulnerable libraries
- Nu HTML test
- Optimal compression
- Optimize images
- Performance budget
- Prefixed CSS first
- scoped-svg-styles
- Specify button type
- SSL server test
- TypeScript configuration hints set
- Unneeded HTTP headers
- Use `Strict-Transport-Security` header
- Use `X-Content-Type-Options` header
- Use Apple touch icon
- Use charset `utf-8`
- Use HTTPS
- Use subresource integrity
- Valid `Set-Cookie` header
- Valid `theme-color`
- Valid manifest
- webpack configuration hints set
Parsers
Server configurations
Troubleshoot
- Api
- Concepts
- Configurations
- Configuring webhint
- Connectors
- Development flow integration
- Extensions
- Formatters
- Hints
- Parsers
- Server configurations
- Troubleshoot
Use subresource integrity (sri
)
sri
warns about requesting scripts or stylesheets without using
subresource integrity.
Why is this important?
A common practice in modern web development is to use third party resources from CDNs or different services (analytics, ads, etc.). However, doing so can increase the attack surface of your web site/app.
While there are techniques to verify the agent is talking with the right server (TLS, HSTS, etc.), an attacker (or administrator) with access to the server can manipulate the content with impunity.
If you want to load a crypto miner on 1,000+ websites you don’t attack 1,000+ websites, you attack the 1 website that they all load content from. (Scott Helme)
Subresource integrity is a standard that mitigates this by ensuring that an exact representation of a resource, and only that representation, loads and executes.
What does the hint check?
This hint checks that a website correctly uses SRI, more specifically:
- All the downloaded resources by an
<script>
or<link rel="stylesheet">
have anintegrity
attribute. - The
integrity
attribute needs to be valid. I.e.: it should contain something in the form ofsha(256|384|512)-HASH
, whereHASH
is the hashed value of the downloaded body’s response using the previously specified algorithm (sha256
,sha384
, orsha512
). - The minimum cryptographic hash function used is
sha384
. If multiple ones are provided, the highest one will be used to determine if the baseline is met. - When using a cross-origin resource (e.g.: using a script hosted in
a third party CDN), the
<script>
or<link>
tag needs to have a validcrossorigin
attribute. - The resource is served on a secure context (i.e.: HTTPS) to guarantee the HTML and resource haven’t been tampered during the delivery.
- The hash from the
integrity
attribute needs to be the same as the one calculated using the response’s body. - If multiple hashes are provided, at least one needs to be valid.
Examples that trigger the hint
Cross-origin resource with no crossorigin
attribute:
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7">
</script> |
Cross-origin resource with invalid crossorigin
attribute:
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="invalid">
</script> |
Cross-origin resource loaded over HTTP
:
<script src="http://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="invalid">
</script> |
Same-origin resource with no integrity
and originCriteria
set to all
:
<link rel="stylesheet" href="/style.css"> |
Examples that pass the hint
Cross-origin resource with multiple hashes and sha384
is one of them:
<script src="https://example.com/script.js"
integrity="sha256-validHashHere
sha384-validHashHere">
</script> |
Cross-origin resource with valid crossorigin
attribute:
<script src="https://example.com/example-framework.js"
integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
crossorigin="anonymous">
</script> |
Can the hint be configured?
Yes, you can define the baseline algorithm and the origin of the resources to analyze.
Baseline algorithm
By default the baseline algorithm is sha384
but you can
change it to sha256
, or sha512
by specifying that in the
.hintrc
file:
{
"connector": {...},
"formatters": [...],
"hints": {
"sri": ["warning", {
"baseline": "sha512"
}],
...
},
...
} |
The above will validate that the integrity
of all scripts and
styles use sha512
.
Origin criteria
By default, this hint will analyze only resources with a different origin.
To change this behavior you will have to set the originCriteria
property
to one of the following:
all
: All resources will be analyzedcrossOrigin
: Only cross-origin resources will be analyzed
The following will analyze all the resources:
{
"connector": {...},
"formatters": [...],
"hints": {
"sri": ["warning", {
"originCriteria": "all"
}],
...
},
...
} |
How to use this hint?
This package is installed automatically by webhint:
npm install hint --save-dev |
To use it, activate it via the .hintrc
configuration file:
{
"connector": {...},
"formatters": [...],
"hints": {
"sri": "error",
...
},
"parsers": [...],
...
} |
Note: The recommended way of running webhint is as a devDependency
of
your project.