I'll catch the gaps attackers look for first

This combination allows any website to make authenticated requests to your API and read the responses. Attackers can steal session tokens, personal data, and perform actions on behalf of authenticated users. Modern browsers block this combination, but misconfigurations can still lead to data leaks in certain scenarios.

TLS 1.0 and 1.1 have known vulnerabilities including BEAST, POODLE, and weak cipher suite support. Major browsers have dropped support for these versions, and PCI DSS compliance requires TLS 1.2 or higher. Using deprecated TLS exposes users to potential data interception.

HTTPS has been a confirmed Google ranking signal since 2014, and Chrome marks HTTP sites as "Not Secure" in the address bar. Users are increasingly wary of sites without HTTPS, especially for e-commerce, login pages, or any page collecting user data. Google's crawler strongly prefers indexing HTTPS versions of pages. Not using HTTPS is effectively giving up a baseline ranking advantage.

Without the Secure flag, cookies (including session tokens) can be intercepted by attackers via man-in-the-middle attacks on unencrypted HTTP connections. This is especially dangerous on public Wi-Fi networks where traffic sniffing is trivial.

Forms that submit to HTTP endpoints transmit user data in plaintext, making it vulnerable to interception by anyone on the network. Chrome and other browsers display prominent security warnings when forms submit to insecure endpoints. This erodes user trust, increases form abandonment, and can violate data protection regulations (GDPR, CCPA).

Mixed content undermines the security guarantees of HTTPS, as HTTP resources can be intercepted and modified by attackers. Browsers display security warnings or block mixed content entirely, breaking page functionality. Google considers HTTPS a ranking signal, and mixed content warnings can erode user trust and increase bounce rates.

Clickjacking attacks trick users into clicking hidden elements by overlaying your page in an invisible iframe on a malicious site. This can lead to unauthorized actions, credential theft, or social engineering. Both X-Frame-Options and CSP frame-ancestors prevent framing by untrusted origins.

Cookies without HttpOnly can be stolen through XSS (Cross-Site Scripting) attacks. If an attacker injects malicious JavaScript, they can read all non-HttpOnly cookies and exfiltrate session tokens or other sensitive data.

Without SameSite, cookies are sent with all cross-site requests by default, enabling CSRF attacks where malicious sites can make authenticated requests on behalf of the user. Modern browsers default to SameSite=Lax, but explicit declaration is recommended for clarity and compatibility.

A wildcard CORS policy allows any malicious website to make authenticated requests to your API and read the responses, potentially exposing user data. While fine for truly public resources (CDN assets, public APIs), it is dangerous for authenticated endpoints. Security breaches can lead to Google Safe Browsing warnings and dramatic traffic loss.

Without SRI, if an attacker compromises a CDN or third-party host, they can inject malicious code into your site. SRI ensures that browsers only execute resources whose content matches a cryptographic hash you specify, protecting against tampered files.

Without HSTS, users who type your domain without https:// or follow an HTTP link will make an initial insecure request before being redirected to HTTPS. During this window, attackers can intercept the connection (SSL stripping attack). HSTS eliminates this vulnerability. While not a direct ranking factor, it is a security best practice that contributes to overall site trustworthiness and is required for HSTS preloading.

Without CSP, the page is more vulnerable to XSS attacks, where attackers inject malicious scripts that can steal user data, session tokens, or redirect users to phishing sites. While CSP is not a direct SEO ranking factor, a security breach can lead to your site being flagged as malicious by Google Safe Browsing, which results in dramatic traffic loss and a warning interstitial in Chrome. Prevention is far easier than recovery.

Open redirects allow attackers to create phishing URLs that start with your trusted domain but redirect to malicious sites. Users and email filters trust your domain, so phishing attacks using open redirects are significantly more effective. Google may also classify your site as potentially harmful if open redirects are exploited at scale.

The primary purpose of CSP is to prevent XSS attacks by controlling which scripts can execute. Using 'unsafe-inline' negates most of this protection, as attackers who find an injection point can execute arbitrary inline scripts. This leaves your site nearly as vulnerable as having no CSP at all.

A short max-age narrows the window in which a returning visitor is protected from a downgrade attack, and it disqualifies the site from browser preload lists. The header is doing part of its job.

Without a Permissions-Policy, any script on your page (including third-party scripts) can access powerful browser APIs like geolocation, camera, microphone, and payment. Restricting these permissions reduces the attack surface if a third-party script is compromised and protects user privacy.

Without a Referrer-Policy, the browser uses the default behavior, which may send the full URL (including query parameters with sensitive data) to external sites. This can leak private information and internal URL structures. Setting a strict referrer policy protects user privacy and your site's internal architecture.

Knowing the exact server software and version helps attackers identify known vulnerabilities to exploit. While security through obscurity is not a primary defense, removing version information raises the bar for automated scanners and script kiddies targeting specific versions.

The X-Powered-By header discloses your application framework, enabling attackers to target framework-specific vulnerabilities. Removing this header is a simple hardening step that reduces your attack surface information.

Addresses published in plain text are harvested by scrapers and sold into spam lists, so an inbox that was quiet gets noisy. That is the whole cost — it is not a vulnerability, nothing is exposed that you did not choose to publish, and for many sites the reachability is worth more than the spam.

This is the recommended way to roll out a policy: observe what would break before enforcing. It is progress, not an absence — but until the policy moves to the enforcing header it protects nothing, and rollouts have a way of never finishing.