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.

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.

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.

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.

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.

Clickjacking attacks overlay your page in a transparent iframe, tricking users into clicking elements on your site while believing they are interacting with another site. This can lead to unauthorized actions, data theft, and account compromise. A security breach can result in Google Safe Browsing warnings that devastate organic traffic.

Exposed email addresses and phone numbers are collected by scraper bots and used for spam, phishing, and social engineering attacks. This can lead to increased spam volume and targeted attacks against your organization or users.

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.

If a CDN or third-party is compromised, attackers can modify the scripts your site loads, injecting malicious code that runs on your users' browsers. SRI provides a cryptographic guarantee that the script content matches what you expected. Supply chain attacks on JavaScript libraries are increasingly common.

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.

When DNS prefetching is enabled, the browser resolves domain names for links on the page before the user clicks them. While this improves performance, it can leak user browsing intentions to DNS servers and network observers, which may be a privacy concern for sensitive applications.

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.