What are Base44 security best practices?

The best practices specific to Base44 (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 Base44 apps, based on the risks that appear in real Base44 deployments.

1. Close: Exposed API Keys

OpenAI, Stripe, and other secret keys embedded in frontend code. Attackers can extract these and abuse your API quotas or access sensitive services.

2. Close: Database Exposure

Supabase or Firebase tables accessible without proper Row Level Security or Security Rules, allowing unauthorized data access.

3. Close: Missing Security Headers

Lack of Content-Security-Policy, Strict-Transport-Security, and other headers leaves your app vulnerable to XSS and MITM attacks.

4. Close: Weak Authentication

No password requirements, missing email verification, and lack of brute force protection on login endpoints.

5. Close: Source Map Exposure

Production source maps revealing your entire application source code, including API endpoints and business logic.

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

The failure mode in Base44 + 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 Base44 app. VAS probes each of secret detection, database security, security headers, auth configuration by actually attempting the attack, not just reading headers or docs.