Security

11 security checks

SEC1

HTTPS

What is it

Checks whether the website uses the secure HTTPS protocol instead of unencrypted HTTP. HTTPS encrypts communication between the browser and server using a TLS certificate, protecting sensitive data (passwords, payment information) from eavesdropping.

Why it matters

Without HTTPS, an attacker on the network can intercept and modify data transmitted between the user and the website (man-in-the-middle attack). Modern browsers mark HTTP pages as 'Not Secure' and many APIs (geolocation, camera, service workers) work exclusively over HTTPS. Google also uses HTTPS as a ranking signal.

Real-world example

Stripe.com has HTTPS on every page including marketing subpages — not just on the payment form. Conversely, a local e-shop without HTTPS displays a 'Not Secure' warning in Chrome's address bar, which discourages customers from making a purchase.

Verified sources

SEC2

Strict-Transport-Security (HSTS)

What is it

Checks for the presence of the Strict-Transport-Security HTTP header with a max-age value of at least 31536000 (1 year). HSTS instructs the browser to automatically send all future requests to the domain over HTTPS, even if the user types http://.

Why it matters

Without HSTS, the first visit over HTTP is vulnerable to SSL stripping attacks — an attacker can intercept the redirect to HTTPS and eavesdrop on the communication. With HSTS, the browser automatically upgrades to HTTPS before even sending the request.

Real-world example

GitHub.com sends the header Strict-Transport-Security: max-age=31536000; includeSubdomains; preload. Thanks to this, the domain github.com is included in the HSTS preload list, so the browser never sends an HTTP request even on the first visit.

Verified sources

SEC3

Content-Security-Policy (CSP)

What is it

Checks for the presence of the Content-Security-Policy HTTP header, which defines from which origins the browser may load scripts, styles, images, and other resources. CSP is the most effective defense against XSS (Cross-Site Scripting) attacks.

Why it matters

XSS is one of the most common web vulnerabilities. An attacker can inject malicious JavaScript that steals cookies, redirects to a phishing site, or modifies page content. CSP prevents the execution of unauthorized scripts by precisely defining allowed sources.

Real-world example

Cloudflare.com uses a strict CSP with the rule script-src 'self', which only allows scripts from its own domain. If an attacker injects an external script from a foreign domain, the browser blocks it because that domain is not on the allowed list.

Verified sources

SEC4

X-Frame-Options

What is it

Checks for the presence of the X-Frame-Options HTTP header, which determines whether a page can be displayed in an iframe, frame, or embed element. The main values are DENY (embedding forbidden) and SAMEORIGIN (allowed only from the same domain).

Why it matters

Without this header, an attacker can embed your page in an invisible iframe on their website and use clickjacking to trick the user into clicking something that actually performs an action on your site — such as approving a payment or changing a password.

Real-world example

Banking portals like mBank use X-Frame-Options: DENY, preventing the login form from being embedded in a foreign iframe. An attacker therefore cannot create a fake page that overlays an iframe with the banking application.

Verified sources

SEC5

X-Content-Type-Options

What is it

Checks for the presence of the X-Content-Type-Options HTTP header with the value nosniff. This header prevents the browser from MIME type sniffing — automatically guessing the content type, which can lead to interpreting a harmless file as an executable script.

Why it matters

Without the nosniff header, a browser may interpret an uploaded text file as JavaScript and execute it. An attacker can thus upload malicious code disguised as an image or text file, which the browser will execute instead of displaying.

Real-world example

Dropbox.com sends X-Content-Type-Options: nosniff with all responses. If someone uploads a file evil.jpg containing JavaScript code, the browser will strictly treat it as an image thanks to nosniff and will not execute the script.

Verified sources

SEC6

Referrer-Policy

What is it

Checks for the presence of the Referrer-Policy HTTP header, which determines how much URL information is sent in the Referer header during navigation or resource loading. The recommended value is strict-origin-when-cross-origin or no-referrer.

Why it matters

Without a proper Referrer-Policy, the URL sent in the Referer header can reveal sensitive data — such as tokens in query parameters, internal URL addresses, or search information. External services (analytics, ads) can thus gain access to data that does not belong to them.

Real-world example

GitHub.com uses Referrer-Policy: strict-origin-when-cross-origin. When you click an external link from a private repository, the target website receives only https://github.com as the referrer — not the full URL with the private repository name.

Verified sources

SEC7

Permissions-Policy

What is it

Checks for the presence of the Permissions-Policy HTTP header (formerly Feature-Policy), which restricts the page's and embedded iframes' access to sensitive browser APIs such as camera, microphone, geolocation, payment API, and others.

Why it matters

Without Permissions-Policy, a malicious iframe embedded via an ad or third-party widget can access the user's camera, microphone, or geolocation. This header allows you to explicitly disable APIs that the website does not need, thereby reducing the attack surface.

Real-world example

Stripe.com sets Permissions-Policy: camera=(), microphone=(), geolocation=(), which disables access to camera, microphone, and geolocation across the entire website. If a malicious script were to get onto the page, it could not activate these sensors.

Verified sources

SEC8

Mixed Content

What is it

Checks whether an HTTPS page contains resources loaded over the unencrypted HTTP protocol (images, scripts, styles, fonts). Such content is called 'mixed content' and compromises the security of the entire page.

Why it matters

Even if the main page is on HTTPS, HTTP resources can be intercepted and modified by an attacker on the network. A malicious script loaded over HTTP on an HTTPS page has full access to the DOM and cookies. Browsers block active mixed content (scripts, iframes) and flag passive content (images) with a warning.

Real-world example

An e-shop on HTTPS loads product images from http://cdn.example.com/product.jpg. Chrome displays a 'Mixed Content' warning in the console and the padlock icon disappears. After changing to https://cdn.example.com/product.jpg, the page is fully secured and the padlock returns.

Verified sources

SEC9

Security Warnings

What is it

Checks whether security warnings appear in the browser console — such as missing security headers, invalid certificates, outdated TLS versions, insecure forms, or CORS policy issues.

Why it matters

Security warnings in the console signal potential vulnerabilities that an attacker can exploit. Ignoring warnings can lead to data leaks, unauthorized access, or compromise of the entire application. A clean console is a sign of a well-secured website.

Real-world example

A website with a form on an HTTP page displays a warning in Chrome about an insecure form target. Cloudflare.com has a clean console with no security warnings, which indicates thorough security across all parts of the website.

Verified sources

SEC10

Insecure Cookies

What is it

Checks whether cookies have the required security attributes set: Secure (sent only over HTTPS), HttpOnly (inaccessible via JavaScript), and SameSite (protection against CSRF attacks). Missing attributes create serious security vulnerabilities.

Why it matters

A cookie without the Secure attribute is also sent over HTTP, where an attacker can intercept it. Without HttpOnly, it can be stolen via an XSS attack through JavaScript cookie access. Without SameSite=Strict or Lax, an attacker can craft a CSRF attack — a fake form that automatically sends a request with the victim's cookie.

Real-world example

Stripe Dashboard sets its session cookie with all three attributes: Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax. Conversely, a website without these attributes risks an attacker stealing the session cookie via XSS and taking over the user's account.

Verified sources

SEC11

Deprecated APIs

What is it

Checks whether the website uses deprecated API calls that browsers plan to or have already stopped supporting. These include synchronous XMLHttpRequest, AppCache, Web SQL, and other obsolete features.

Why it matters

Deprecated APIs often contain security vulnerabilities that will never be fixed. Some deprecated DOM writing methods can be exploited for malicious code injection, and synchronous XHR blocks the main thread. Browsers are gradually removing these APIs, which can cause the website to stop working.

Real-world example

An older website uses deprecated methods to inject scripts into the page instead of modern createElement or async/defer attributes. Chrome blocks these calls on slow connections. GitHub and Cloudflare use exclusively modern APIs, ensuring long-term compatibility.

Verified sources

Try auditing your website

Test your website against all checks and find out what to improve.

Start analysis