5 things that will get your app hacked in the first month
Most small application compromises in the first 90 days after launch come from one of five specific vulnerabilities. They are not sophisticated. They do not require a nation-state attacker or a zero-day exploit. They require a bot or a curious person and a predictable mistake that AI coding tools make regularly. What makes these five dangerous is not their technical complexity but their prevalence: a large fraction of apps built with AI coding tools have all five of these issues when they launch, because the tools that built them did not address any of them by default.
An exposed service role key is the single fastest path to a complete compromise. In Supabase, the service role key bypasses Row Level Security entirely and has full read, write, update, and delete access to every table in your database. When it appears in a client-side JavaScript bundle — which happens when it is placed in a NEXT_PUBLIC_ environment variable — any visitor to your site can extract it in under thirty seconds using browser DevTools and then use the Supabase JavaScript client to query your entire database without authentication. Attackers run automated scanners that check for this specific pattern across thousands of sites simultaneously. If your service role key is in your bundle, the window between launch and compromise can be as short as a few hours.
No rate limiting on authentication endpoints is the second most commonly exploited gap. Credential stuffing attacks — testing millions of known username and password combinations from past data breaches — are fully automated. The tooling is cheap, the credential lists are widely available, and the process requires no human effort once started. Without rate limiting, your login endpoint will accept and process these requests at the same speed as any other request, potentially validating thousands of credential pairs per hour. Even if none of the tested credentials succeed immediately, the attack consumes server resources, generates noise in your logs, and will eventually find a match if any of your users reuse passwords from breached services. Rate limiting — refusing more than a handful of login attempts from the same IP in a short window — stops this attack almost entirely.
SQL injection through unparameterized queries is older than most of the readers of this article, but AI coding tools still generate it. When user-provided input is concatenated directly into a SQL query string — rather than passed as a parameter to a prepared statement — an attacker can manipulate the query's logic by including SQL syntax in their input. A login form vulnerable to SQL injection can be bypassed without knowing any user's password. A search field vulnerable to SQL injection can be used to exfiltrate your entire database. Supabase's query builder is safe by default, but if your AI tool generated raw SQL strings using template literals with user input, those queries are likely vulnerable.
Sensitive API routes with no authentication check are the stealth vulnerability: invisible in the UI, obvious in the URL structure. When you ask an AI to build a data export feature, an admin panel, or a billing management page, it creates a route that serves that functionality. If the route handler does not independently verify the session — relying instead on the UI to hide the link from unauthorized users — any user who knows or guesses the URL can access it directly, bypassing the visual gate entirely. This is the pattern that produces incidents where a regular user discovers they can access an admin endpoint simply by typing the URL, or where a user can download another user's data by changing an ID in a URL parameter.
Secrets committed to a public git repository are the least recoverable of the five problems, because git history is permanent. When a key is committed to a public repository, it is indexed by GitHub, by automated scanners, and by anyone who clones the repository — even if you delete the file and commit the deletion, the key remains in the history and is accessible via git log and the GitHub API. GitHub Secret Scanning will alert the affected service providers automatically, and many providers will revoke the key, but by the time revocation happens, the key may already have been extracted and used. The right response to any key that has been in a public repository — regardless of how briefly — is immediate rotation. The right prevention is .env* in .gitignore before the first commit, and a pre-commit hook that scans for secrets before they reach the repository.