Can Netlify apps be hacked?

Netlify-Specific Attack Vectors

These are the paths attackers actually take into Netlify applications — not a generic OWASP list, but what automated scanners and security researchers find when they look at Netlify apps specifically, given the stack (Supabase (Postgres + RLS) as the database):

1. **Build-Time Secret Exposure**: Build-time env vars get baked into static HTML, visible to anyone.

2. **Deploy Preview Exposure**: Preview deployments expose unreleased features publicly.

3. **Missing _headers File**: Security headers not configured by default.

4. **Form Spam Without Protection**: Netlify Forms are public endpoints vulnerable to spam.

5. **Function Timeout Attacks**: 10s timeout (26s paid) can be exploited for resource exhaustion.

**Supabase-Specific Risk**: Netlify apps typically ship with the public Supabase anon key embedded in frontend code. That is by design — but only works safely if Row Level Security is enabled on every table. Attackers routinely query Supabase endpoints directly using the anon key from your bundle. A single table without RLS is a full data leak.

How these issues get discovered

This isn't targeted — automated scanners run across the entire internet looking for known patterns, and Netlify apps surface like everything else. Supabase URLs follow a predictable pattern (`*.supabase.co`), making Netlify apps easy to fingerprint. Once identified, the scanner probes the specific vulnerability classes listed above.

What a security scan of a Netlify app looks at

• **Environment Config** — Review environment variable setup.
• **Functions Security** — Check serverless function security.
• **Headers Setup** — Verify _headers file configuration.
• **Form Security** — Check form handling and spam protection.