No protocol-relative URLs
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
No protocol-relative URLs (no-protocol-relative-urls
)
no-protocol-relative-urls
warns against using scheme-relative URLs
(commonly known as protocol-relative URLs).
Why is this important?
A shorthand way of specifying URLs is to remove the protocol and let the browser determine the relative protocol based on the current connection to the resource.
As the web moves towards HTTPS everywhere, the use of protocol-relative URLs has become an anti-pattern, exposing some sites to man in the middle compromises and is therefore best avoided.
Particularly for web sites/apps served over HTTP, other drawbacks when using protocol relative URLs include:
Performance
If the web site/app is served over HTTP, for every protocol-relative URL that does support HTTPS and:
does a redirect to it (i.e. most CDNs), the load time will take longer than if the request was made directly to the
https://
version of the URL.does not redirect to it, you may be missing out on things such as Brotli compression and HTTP/2 that are only supported by browsers over HTTPS.
Security
If protocol-relative URLs are used for CDN links, their domain is not in the browser’s HSTS preload list, and the first request is not made over HTTP, there is a high risk of man-in-the-middle attacks.
Of course, if the web site/app is served over HTTP it is already exposed to those types of attacks, but in general CDNs constitute a high-value target, and therefore, are much more likely to be attacked than most of the individual sites that use them.
What does the hint check?
The hint checks for protocol-relative URLs.
Note: Currently the hint does not check for protocol-relative URLs inside of stylesheets and scripts.
Let’s presume example1.com
does not support HTTPS and example2.com
does.
Examples that trigger the hint
<link rel="stylesheet" href="//example1.com/style.css"> |
<script src="//example2.com/script.js"></script> |
Examples that pass the hint
<link rel="stylesheet" href="http://example1.com/style.css"> |
<script src="https://example2.com/script.js"></script> |
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": {
"no-protocol-relative-urls": "error",
...
},
"parsers": [...],
...
} |
Note: The recommended way of running webhint is as a devDependency
of
your project.