Vulnerabilities
What goes wrong with access to web application data — explained in plain language, with consequences and fixes.
Anyone can open someone else's record
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.
A regular user can perform admin actions
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.
One company's users can see another company's data
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.
Users can change fields that are not theirs to change
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.
Data is available without signing in at all
Some addresses in your app return data to anyone who opens them — no sign-in required. These are usually forgotten internal or temporary pages.
A password reset link can be used to enter someone else's account
The password recovery link is predictable, never expires, or works more than once. Whoever obtains or guesses it can sign in as that user.
Anyone can change someone else's data
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 app uses a library with a known vulnerability
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 require a secure connection
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.
Error messages reveal how your app is built
On failure your app shows visitors technical details: server file paths, database queries, library versions.
The full user list can be downloaded
Your app lets anyone request every user at once — with no size limit and no check on why they are needed.
An internal configuration file is readable by anyone
A configuration file that belongs on the server is served to anyone who
Version control data is published with your app
The hidden folder your version control system uses was deployed together
Your app is missing recommended browser protections
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.
Session cookies can be stolen or misused
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.
Any website can read responses from your API
Your app tells browsers that any website may read its responses, and in some cases may do so with the visitor's credentials attached.
Browsers refuse to open your app
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.
Your certificate expires soon
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.
PTR Record Found
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.
Weak Encryption Detected
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.
Your page is slow for real visitors
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.
Your app throws errors in the visitor's browser
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.
Parts of your page fail to load
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.
An access key is visible in your page source
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.
A full-access service key reached the browser
Your page source contains a service key that bypasses every access rule for your database. That key belongs on the server only.
Your page is hidden from search engines
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.
Search engines have nothing to show for your page
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.
Search engines cannot find your sitemap or rules
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.
Your pages are sent uncompressed
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.
Returning visitors download your files again every time
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.
Anyone visiting your site can read a database table
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.
Access control is configured but lets everyone through
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.
Uploaded files are readable by anyone with the link
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.