# Bezpečnosť — Glossary of Checks 11 bezpečnostných kontrol --- ## 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. ### Sources - [Why HTTPS Matters](https://web.dev/articles/why-https-matters) — web.dev - [Transport Layer Security (TLS)](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Transport_Layer_Security) — MDN --- ## 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. ### Sources - [Strict-Transport-Security header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security) — MDN - [HTTP Strict Transport Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) — OWASP --- ## 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. ### Sources - [Content-Security-Policy (CSP) header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) — MDN - [Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) — OWASP --- ## 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. ### Sources - [X-Frame-Options header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options) — MDN - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) — OWASP --- ## 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. ### Sources - [X-Content-Type-Options header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options) — MDN - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) — OWASP --- ## 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. ### Sources - [Referrer-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy) — MDN - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) — OWASP --- ## 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. ### Sources - [Permissions-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy) — MDN - [Permissions Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Permissions_Policy) — MDN --- ## 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. ### Sources - [Mixed content](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Mixed_content) — MDN - [Content Security Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) — MDN --- ## 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. ### Sources - [Security on the web](https://developer.mozilla.org/en-US/docs/Web/Security) — MDN - [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/) — OWASP --- ## 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. ### Sources - [Set-Cookie header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) — MDN - [Secure cookie configuration](https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies) — MDN --- ## 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. ### Sources - [Security on the web](https://developer.mozilla.org/en-US/docs/Web/Security) — MDN - [HTTP Headers Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) — OWASP ---