Netlify-spezifische Exposure

Netlify follows the same pattern as every PaaS: distinctive headers, characteristic file paths, and a per-deploy preview URL system that's a wonderful CI feature and an occasional security liability. The bugs are mostly the same as Vercel's, with Netlify-specific shapes — `x-nf-request-id` instead of `x-vercel-id`, `*.netlify.app` preview hosts instead of `*.vercel.app`, `_redirects` and `_headers` files that occasionally ship to production with rules they shouldn't.

Netlify adds `x-nf-request-id` and (for some plan tiers) `server: Netlify` to every response. The `_redirects` file at the build root configures URL rewrites and proxy rules; if it includes wildcards or admin-route rules, those rules apply to public traffic. The `_headers` file similarly controls response headers. Preview deployments live at `deploy-preview-N--sitename.netlify.app` per pull request — discoverable via search-engine indexing or wayback archives if anything internal-only ever links to them.

Mostly recon — confirms Netlify as the host, hints at the build pipeline. Direct impact when preview URLs leak (preview deployments often have less strict access controls), or when `_redirects` rules include unintended proxy patterns that expose backend services through the Netlify edge.

Don't expose preview deploy URLs from production code or shared documents. Audit your `_redirects` file for unintended wildcards or proxy rules — `/* /admin/:splat 200` is the kind of rule that looks innocuous until you realize it forwards every path to admin. Use Netlify's site password protection for non-production environments. Set a strict `robots.txt` on preview deploys (Netlify supports per-context robots configuration). For high-stakes deployments, pin every preview to a private team-only password-gated context.