How Websites Get Hacked & How to Defend Yours: XSS, CSRF, SSRF, .env Leaks, CSP, SRI & Least Privilege

1. Why Real-World Breaches Look Embarrassingly Simple in Postmortems

Reading twenty real incident forensics teaches one humbling lesson: attackers rarely crack AES-256 encryption. Instead, breaches repeatedly trace back to five developer shortcuts — committing `.env` files or exposing `/.git` directories behind misconfigured Nginx servers, interpolating raw user strings inside SQL or HTML sinks (SQLi & XSS), trusting user-supplied webhook URLs inside backend fetchers (SSRF hitting AWS/GCP metadata endpoints), skipping SameSite/CSRF token checks on state-changing cookies, or assigning wildcard IAM permissions to convenience containers.

2. Cross-Site Scripting (XSS), Content-Security-Policy & Subresource Integrity (SRI)

Stored or Reflected XSS occurs whenever untrusted text (a profile name, markdown comment, URL query parameter, or JSON-LD blog script!) renders directly into DOM HTML or inline scripts without strict context-aware escaping. Inside React/Next.js, JSX text interpolation escapes entities automatically, but reaching for dangerouslySetInnerHTML, constructing dynamic href="javascript:..." links, or serializing raw JSON inside <script> tags without escaping "<" into "\u003c" reopens script injection immediately.

Defense in depth stacks three layers: (1) Always validate protocols (`https:` / `http:` only) and sanitize unavoidable rich HTML with DOMPurify, (2) Store auth sessions exclusively inside HttpOnly + Secure + SameSite=Lax cookies so even injected scripts cannot read tokens via document.cookie, and (3) Enforce strict Content-Security-Policy headers restricting script execution plus integrity="sha384-..." (SRI) hashes on any third-party CDN scripts.

// 1. Safe JSON-LD serialization (never allow </script> breakout)
<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{ __html: JSON.stringify(schema).replace(/</g, '\\u003c') }}
/>

// 2. HTTP Defense-in-Depth Response Headers (next.config.js)
[
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
]

3. CSRF, SSRF, Rate Limiting & Least-Privilege Secret Hygiene

Cross-Site Request Forgery (CSRF) tricks an authenticated user’s browser into sending hidden POST requests using ambient cookies. Defend every mutation endpoint with SameSite=Lax or Strict cookies combined with custom header/Origin verification and anti-CSRF tokens on legacy cross-origin flows.

Server-Side Request Forgery (SSRF) strikes whenever your server downloads URLs supplied by users (link previews, webhooks, PDF generators, RAG web scrapers). Never just reject string matches for "localhost": attackers use decimal IPs, IPv6 ::ffff:127.0.0.1, HTTP 302 redirects, or DNS rebinding to pivot straight into http://169.254.169.254/latest/meta-data/ and steal cloud IAM role credentials! Always resolve DNS explicitly first, deny private/loopback/link-local CIDRs, disable cross-host auto-redirects, and apply strict egress firewall rules.

Finally, lock down secret discipline: audit every NEXT_PUBLIC_ environment variable (anything prefixed NEXT_PUBLIC_ is bundled straight into public client JavaScript!), rotate leaked keys rather than merely force-pushing Git commits, and keep transactional API keys strictly server-side with per-IP rate limits.

import dns from 'node:dns/promises';
import net from 'node:net';

function isBlockedPrivateIp(ip) {
  // Block IPv4 loopback, RFC1918 private ranges, CGNAT, and cloud IMDS 169.254.x.x
  if (!net.isIPv4(ip)) return ip === '::1' || ip.startsWith('fc') || ip.startsWith('fd') || ip.startsWith('fe80') || ip.includes('169.254.');
  const [a, b] = ip.split('.').map(Number);
  return a === 10 || a === 127 || a === 0 || (a === 172 && b >= 16 && b <= 31) || (a === 192 && b === 168) || (a === 169 && b === 254);
}

export async function safeFetchExternalUrl(rawUrl) {
  const parsed = new URL(rawUrl);
  if (parsed.protocol !== 'https:') throw new Error('Only HTTPS allowed');
  const { address } = await dns.lookup(parsed.hostname);
  if (isBlockedPrivateIp(address)) throw new Error('Blocked private or metadata IP target');
  return fetch(parsed.toString(), { redirect: 'manual', signal: AbortSignal.timeout(5000) });
}

4. Incident Response Checklist When Credentials or Endpoints Leak

Mistakes still happen even in security-conscious teams — what distinguishes mature web builders from panicked teams is rapid, ordered containment. Never attempt simply overwriting or force-pushing Git commit history after pushing an API key, SMTP password, or cloud token onto GitHub: automated scanner bots scrape public push streams within four seconds of commit creation! Always treat committed secrets as permanently compromised.

Execute containment cleanly in order: (1) Rotate and revoke the leaked key immediately at the upstream provider (AWS IAM, Resend, Stripe, OpenAI) before rewriting git commits; (2) Audit cloud provider access logs across the exposure window to detect unauthorized API traffic or lateral privilege creation; (3) Move secret injection strictly into managed deployment secrets or runtime IAM roles; and (4) Install pre-commit secret scanning hooks (`gitleaks`) alongside least-privilege IP/scope restrictions so accidental exposure becomes structurally impossible going forward.

Pair secret hygiene with strict HTTP perimeter discipline: enable Strict-Transport-Security (HSTS), terminate stale TLS ciphers, validate file uploads strictly by server-inspected MIME headers rather than client filenames, and keep third-party webhook verification signatures constant-time checked (`crypto.timingSafeEqual`). Consistent baseline habits wipe out 90% of opportunistic breaches completely.