We audit startup web apps for a living. Here are the security holes we keep finding over and over.

I run CyberPantheon, an offensive security company. We break into web applications before the bad guys do. Most of our clients are startups and small companies who built something fast and are now realizing they might have left the front door wide open.

I want to share the 4 most common vulnerabilities we find, because every founder reading this probably has at least one of them. I am not naming any clients. These are patterns, not callouts.

1. Exposed API keys in JavaScript bundles

This is the most painful one because it is so easy to check and so devastating when exploited. We audit Next.js and React apps regularly. We download the production JS bundle, run a quick grep for patterns like sk-, pk_, AIza, and key_. Almost every time, we find at least one API key sitting in plain text in client-side JavaScript. These are OpenAI keys, Stripe test keys, Supabase anon keys, sometimes even database connection strings. Anyone who opens DevTools can grab them. We have found keys that, if abused, could have cost the startup thousands of dollars in LLM credits in hours. One key belonged to a service with direct access to customer data.

How to check right now: Open your production site, open DevTools, go to the Network tab, filter by JS files, and search your bundle for common key prefixes. If you find anything, rotate it immediately and move it to a server-side environment variable.

2. Row Level Security bypasses in Supabase

Supabase is incredible for moving fast. But the default RLS (Row Level Security) policies are a trap. We find two patterns constantly. First, developers create RLS policies but forget to enable RLS on the table itself. The policies exist but are never enforced. Second, they use auth.uid() in policies but the anon key is still public, meaning unauthenticated requests can hit endpoints that assume authentication. We have seen user tables, payment records, and entire databases exposed because of this. In one case, we could read every user's email and subscription status without being logged in.

How to check right now: Go to your Supabase dashboard, open the Table Editor, and verify that RLS is actually toggled ON for every table that contains user data. Then test your API from an incognito window with no auth headers.

3. Missing authentication on internal API routes

Startups build API routes for admin functions, webhooks, and internal tools. Then they deploy them without authentication because "nobody knows the URL." We find these by fuzzing common endpoint patterns: /api/admin, /api/debug, /api/webhooks/stripe, /api/internal/. Some of these return sensitive data with zero auth. Others accept POST requests that trigger actions. We found one endpoint that let us create admin user accounts without any authentication at all. The founder had built it for initial setup and forgot it was live.

How to check right now: Audit every API route in your codebase. If it does not have middleware that verifies authentication and authorization, it is exposed. No exceptions.

4. No Content Security Policy headers

This one is less glamorous but more common than all the others combined. A Content Security Policy (CSP) header tells the browser which scripts are allowed to run on your site. Without it, an attacker who finds any XSS vulnerability (and XSS is everywhere) can inject malicious scripts that steal session tokens, redirect users, or deface your site. We run a header check on every prospect before our first call. Most startups score zero on security headers. Adding a basic CSP takes 10 minutes and eliminates an entire class of attacks.

How to check right now: Go to securityheaders.com and paste your URL. If your score is not an A, you have work to do.

Why am I posting this? Two reasons. First, these are fixes you can make today for free. Go do it. Second, this is what we do at CyberPantheon. We find the gaps you did not know existed, we show you exactly how an attacker would exploit them, and we give you a prioritized remediation plan. Not a checklist. A real attack map.

If you are building something and you are not sure if your security is solid, that uncertainty is worth resolving before you have users, before you raise money, before someone finds the gap for you.

We do free 15-minute preliminary assessments. Link is on our profile.