What are Netlify security best practices?

The best practices specific to Netlify (not generic OWASP)

Every "security best practices" list tells you to use HTTPS and rotate keys. Those are table stakes. The list below is what actually matters for Netlify apps, based on the risks that appear in real Netlify deployments.

1. Use Netlify Functions for runtime secrets

*Why:* Build-time env vars get baked into static HTML, visible to anyone. *Do this:* Use Netlify Functions for runtime secrets. Never build-time for secrets.

2. Password-protect deploy previews in Site settings

*Why:* Preview deployments expose unreleased features publicly. *Do this:* Password-protect deploy previews in Site settings.

3. Create _headers file with CSP, X-Frame-Options, HSTS

*Why:* Security headers not configured by default. *Do this:* Create _headers file with CSP, X-Frame-Options, HSTS.

4. Enable Akismet or reCAPTCHA on all forms

*Why:* Netlify Forms are public endpoints vulnerable to spam. *Do this:* Enable Akismet or reCAPTCHA on all forms.

5. Add rate limiting

*Why:* 10s timeout (26s paid) can be exploited for resource exhaustion. *Do this:* Add rate limiting. Set appropriate timeout limits.

Netlify-specific: audit every table for RLS before every deploy

The failure mode in Netlify + Supabase apps is always the same: a table gets added during a feature push, RLS never gets turned on, the full table becomes queryable via the anon key. Bake a pre-deploy check: `select tablename from pg_tables where schemaname = 'public' and not rowsecurity` — the result must be empty.

Verification

Even perfect best practices don't prove themselves — the only way to confirm the list above is implemented is to scan a deployed Netlify app. VAS probes each of environment config, functions security, headers setup, form security by actually attempting the attack, not just reading headers or docs.