Five things that show up in apps built fast

Where this comes from

Today's tools let you stand up a working system in a week. They do it well: the database, sign-in, file uploads and the interface come from ready-made building blocks.

What they don't do is keep track of who gets to see whose data. That stays with the person assembling the app, and it is exactly the part that is easiest to forget, because without it the app still looks like it works.

The five below are not rare cases. They are what shows up most often.

1. The access rule exists, but not on every table

A typical sequence: someone enables access control on the orders table, because that is obvious. The invoices table, added three weeks later, is left without a rule.

The interface doesn't show this, because the interface asks the database for the signed-in user's data. The problem only becomes visible when someone queries the database directly, bypassing the interface. The key needed for such a query is in the browser, because it has to be.

How to check: list every table and mark whether each one has a rule. Don't ask the code, ask the database. A list of tables without rules is a list of open doors.

2. The rule locks down reads, but not writes

A second version of the same problem, harder to notice. There is a rule for reads, so the “can I see other people's data” test comes back green and everyone relaxes.

Meanwhile, inserts and updates are separate operations with separate rules. Without an update rule you can take your own row and move it to someone else's account, or the other way round.

How to check: for every table, check the four operations separately, not just one. A green read proves nothing about writes.

3. A key with full access ends up in the browser

Most systems have two keys: a public one that is safe to expose, and a service key that bypasses every access rule.

The service key usually reaches the browser in one of two ways. Either through an admin view where someone needed “broader access for a moment”. Or through an environment variable named in a way that made the build tool treat it as public.

This is the worst of the five, because it cancels out every other safeguard. You can have perfect access rules and get nothing from them.

How to check: open the app, go to the sources the browser has loaded and search them for a fragment of your service key. It takes two minutes.

4. Attachments without a rule and with a predictable URL

Files go to a separate storage bucket with its own access rules, and that is the moment when they are easy to overlook.

It gets serious when file names are generated from a sequential number. Then there is nothing to guess: you just decrease the number in the URL by one.

How to check: download your own attachment, change the number in the URL and repeat the request. If the file downloads, you have your answer.

5. Routes nobody remembers anymore

A diagnostics panel, a test route, an old version of the API, an endpoint for checking database health. They are created during the build and stay after deployment.

On their own they rarely expose customer data. They do make reconnaissance easier, though, and sometimes give away variable names or library versions.

How to check: list every route the app serves and, for each one, answer whether it is allowed to work without sign-in. If you can't justify why it is public, it probably shouldn't be.

What this list does not cover

These are the five most common, not the full set. There is nothing here about vulnerabilities in libraries, business logic errors, session problems or anything related to resilience under load.

Passing this list doesn't mean the app is secure. It means it doesn't have the five most common problems. Those are two different things, and it is worth keeping them apart, especially when talking to a client.