What goes wrong, and what to do about it

Your app returns records by their number without checking who owns them. Change one digit in the address and you see another customer's order, profile or document.

Administrative actions — deleting data, exporting user lists, changing settings — work for anyone who knows the address. The button is hidden in the interface, but the request still succeeds.

Your app serves several companies or workspaces, but database queries are not limited to the user's own workspace. Guess an identifier and a neighbouring company's data opens up.

When saving a form, your app accepts whatever fields arrive. A user can add a field that is not on the screen — a role or a balance — and it will be saved.

Some addresses in your app return data to anyone who opens them — no sign-in required. These are usually forgotten internal or temporary pages.

The password recovery link is predictable, never expires, or works more than once. Whoever obtains or guesses it can sign in as that user.

Your app checks who is signed in before saving a change, but not whether the record being changed belongs to them. Anyone with an account can edit another customer's order, document or profile by sending the record number.

Your database is reachable directly from the browser and this table has no row-level access control. Any visitor can download it in full — along with your customers' email addresses and phone numbers.

Row-level access control is switched on for this table, but the condition in the rule matches everybody. Your dashboard shows a green checkmark while the data is open to all.

Your file storage is open for reading. Documents, scans and photos uploaded by users are available to anyone who knows or guesses the file address.

Your app depends on a third-party library with a publicly documented vulnerability. A fix is usually available; the update simply has not been applied.

Your app does not tell browsers to talk to it over a secure connection only. A user's first request can travel in the clear — along with whatever they type.

On failure your app shows visitors technical details: server file paths, database queries, library versions.

Your app lets anyone request every user at once — with no size limit and no check on why they are needed.

A configuration file that belongs on the server is served to anyone who

The hidden folder your version control system uses was deployed together

Browsers offer several protections that only work when your app asks for them: restricting where scripts may load from, refusing to be framed by other sites, and not guessing file types. Your app does not ask.

Your app sets cookies without the flags that keep them safe: they can be read by scripts, sent over an insecure connection, or attached to requests coming from other sites.

Your app tells browsers that any website may read its responses, and in some cases may do so with the visitor's credentials attached.

The security certificate your site presents is not one browsers accept. Visitors see a full-page warning before they see your app, and most of them leave at that point.

The certificate your site uses runs out shortly. On that day browsers stop opening the app and show a warning instead — there is no grace period.

A PTR record, also known as a Pointer Record, was detected. This record links an IP address to a domain name, essentially providing a reverse lookup of your domain.

Your app is using weak encryption methods to secure data. This means the data might not be as protected as it should be when being transmitted over the internet.

A parameter on your app is pasted straight into a database query. By adding a piece of a query to it, someone can change what the database returns — reading records they should never see, and often changing or deleting them too.

The code your app sends to browsers contains an access key for an external service. Every visitor can see it by viewing the page source.

Your page source contains a service key that bypasses every access rule for your database. That key belongs on the server only.

When a visitor opens your app, its code fails in their browser. Errors like this usually mean part of the page silently stops working — a form does not submit, a list stays empty, a button does nothing — while the page itself still looks fine to you.

Some files your page asks for come back missing or with an error — an image, a stylesheet, a script or an API call. The page still opens, so the failure is easy to miss, but the visitor sees a broken layout, a missing picture or a button that does nothing.

The page tells search engines not to index it. Google and others will drop it from results — the site is live, looks fine to visitors, and is invisible to anyone searching for it.

The page has no title, no description or no main heading. These are the lines search engines print in results and social networks show when someone shares your link — without them the entry is built from whatever text the crawler happens to find.

Your site does not publish a robots.txt file, a sitemap, or both. A sitemap is the list of pages you want indexed; robots.txt is where crawlers look first to learn the rules and find that list.

The server sends text — HTML, JavaScript, CSS — without compressing it. Compression is a one-line setting and typically cuts what the visitor has to download by three to five times.

Your scripts and stylesheets come without caching instructions, so a browser that already has them downloads them again on the next visit instead of reusing what it stored.

Measured on a throttled connection — the way a visitor on mobile data actually loads it — your page scores below half of what it could. On your own machine, with a fast connection and a warm cache, the same page feels instant, which is why this stays unnoticed.