A real report, on an app we built to fail

Your secret settings file is downloadable by anyone. It usually holds passwords and keys that let someone take over your app and your accounts.

Served real file contents at /.env (first bytes matched the expected format).

One paste into the tool that built your app

What to doStop serving this file to the public, then change every password and key it contained, because they must be treated as leaked.

A secret Stripe key is written straight into your website's code, where anyone who visits can copy it. Someone can use it to run up charges on your account or reach whatever it unlocks.

Found "A secret Stripe key" in the site's JavaScript, downloadable by anyone.

One paste into the tool that built your app

What to doRemove this from the code that runs in the browser, keep it on your server only, and replace it, because it must be treated as already leaked.

A password or key for one of the services your app uses is written straight into your website's code, where anyone who visits can copy it. Someone can use it to run up charges on your account or reach whatever it unlocks.

Found "A password or key for one of the services your app uses" in the site's JavaScript, downloadable by anyone.

One paste into the tool that built your app

What to doRemove this from the code that runs in the browser, keep it on your server only, and replace it, because it must be treated as already leaked.

A secret Stripe key, which can move money is saved inside your project files, in .env. Anyone who can see your code can copy it and use it as though they were you.

found in .env

A few clicks in a dashboard

What to doTreat it as already known to strangers. Make a new one, put the new one in your hosting settings, and switch the old one off so the copy that leaked stops working.

1. Open the dashboard of the service this key belongs to and create a fresh one.
2. Put the new key into your hosting settings, not into a file in your project.
3. Switch off the old key so the copy that leaked stops working.

A full copy of your database is saved inside your project, in dump.sql, covering 2 of your tables including users, orders. Anyone who can see your code can download all of it at once.

2 table(s) with rows in them

One paste into the tool that built your app

What to doTake the file out of your project, and treat everything in it as seen by strangers. If it holds people who trusted you with their details, you may have to tell them.

Your "customers" list, which holds email, full_name, phone, has no rules at all about who may read it. Anyone who finds the address can take the whole thing.

no access rules are switched on

One paste into the tool that built your app

What to doSwitch the rules on for this list, then add one saying a person can only see their own entries.

Anyone who signs up to your app can read your entire "orders" list, which holds user_id, email, total. Not just their own entries, everybody's. Signing up takes seconds and anyone can do it.

the rule allows: auth.role() = 'authenticated'

One paste into the tool that built your app

What to doChange the rule so it also checks the entry belongs to the person asking.

Your master key is in the part of your app that every visitor downloads, in src/lib/db.ts. That key ignores every rule you have set about who can see what. Anyone who looks can read, change or delete everything you hold, including every customer record.

process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!,

A few clicks in a dashboard

What to doTreat that key as already known to strangers. Make a new one, keep it on the server only, and make sure the part visitors download uses the public key instead.

1. Open your Supabase dashboard, go to Project Settings and then API.
2. Create a fresh service role key. The old one stops working straight away.
3. Put the new key into your hosting settings under a name that does not start with NEXT_PUBLIC, VITE or REACT_APP.

Your app uses Twilio, which charges you every time. Nothing limits how often a stranger can set that off. One person running a simple script, at one text message a second, would cost you around 680 dollars a day. Left for a month that is roughly 20400 dollars, and the invoice is how you would find out. We found this by reading your code.

When it mattersThe day somebody decides to. Nothing is spent until a stranger finds the page that calls Twilio, and the figures above assume they run one request a second. Before launch this is a sentence; after launch it is a bill.

One paste into the tool that built your app

What to doPut a cap on the parts that spend money, starting with the one that uses Twilio. A few requests a minute from the same visitor is plenty for a real person.

In one place your app builds an instruction out of whatever a visitor typed into a box. Someone who types the right thing can make it run their instruction instead of yours, and read or delete anything you hold. We found this by reading your code, starting at src/app/api/notify/route.ts.

One paste into the tool that built your app

What to doEverywhere a visitor supplied value reaches your database or your server, it has to be passed as a value and never joined onto the instruction itself.

In 2 places your app scrambles something private using a method that is no longer considered safe, or invents a supposedly secret value in a way that can be guessed. We found this by reading your code, starting at src/app/api/notify/route.ts.

One paste into the tool that built your app

What to doSwitch to a current method, and make anything that has to be unguessable using a proper random source rather than an ordinary one.

In one place your app runs text as if it were part of your own program. If any of that text can be influenced by a visitor, they can make your app do whatever they like. We found this by reading your code, starting at src/app/api/notify/route.ts.

One paste into the tool that built your app

What to doReplace it with something that reads the value instead of running it. There is almost always a direct alternative.

Your app takes the visitor at their word about who they are, in src/app/api/notify/route.ts. Someone can simply say they are a different customer and be handed that person's information. We found this by reading your code.

One paste into the tool that built your app

What to doTake who they are from the signed in session on the server, and ignore whatever the request claims.

Nothing in your app checks that what a visitor sends is the shape you expected, across its one working part. Odd or deliberately nasty input then reaches your database, which is how data gets corrupted and how attacks get in. We found this by reading your code.

One paste into the tool that built your app

What to doDescribe what each part expects to receive, and refuse anything that does not match, before it touches your data.

A backup file is saved inside your project, src/config.js.bak. Backups often hold an older copy of something that was later cleaned up, so this can quietly publish a thing you thought you had removed.

a backup of another file

One paste into the tool that built your app

What to doLook at what is inside it, then take it out of your project.

If someone sneaks bad code onto a page your visitors load, nothing on your site stops it from running.

When it mattersWhen your site takes anything typed by a visitor and shows it back, like comments, names or messages. A site that only shows your own words has less at stake.

One paste into the tool that built your app

What to doPaste the fix below into the tool that built your app. It adds a rule listing which sources of code your site trusts. Check the site still works afterwards, because a rule that is too strict blocks your own code too.

A visitor on public wifi could be pushed onto an insecure connection without noticing, and have their session stolen.

Your page was missing this setting. Its technical name, for whoever fixes it: strict-transport-security.

When it mattersOnce people sign in on your site. Before that there is no session for anybody to steal.

One paste into the tool that built your app

What to doOn a service like Vercel or Netlify this is usually handled for you already. Otherwise paste the fix below into the tool that built your app.

Someone could load your site invisibly inside their own page to trick your users into clicking things they did not mean to.

Your page was missing this setting. Its technical name, for whoever fixes it: x-frame-options.

When it mattersOnly once your site has something worth tricking people out of, like a sign in or a payment. On a brochure site it is worth doing and not worth losing sleep over.

One paste into the tool that built your app

What to doThere is no switch for this in a dashboard. Paste the fix below into the tool that built your app and it adds the missing rule.

A browser could treat one of your files as a different, more dangerous type of file than you intended.

Your page was missing this setting. Its technical name, for whoever fixes it: x-content-type-options.

When it mattersRarely on its own. It closes a door that other problems would need open, so it is the kind of thing to tidy up in a spare hour rather than today.

One paste into the tool that built your app

What to doThis is one line your app sends with every page, not a dashboard setting. Paste the fix below into the tool that built your app.

Your site carries a Google key for a Google service. That is normal for this kind of key, but it is only safe when it is limited to your website. If it is not, anyone can copy it and use up its allowance, and that part of your site stops working until the next day.

A Google key used for a Google service from the browser.

A few clicks in a dashboard

What to doIn Google Cloud, limit this key to your website address and to the one service it is for.

1. Sign in to Google Cloud at console.cloud.google.com and choose your project.
2. Go to the page called Credentials and open this key.
3. Under the website limits, add your own site address, for example yourapp.com/*.
4. Under the service limits, choose only a Google service. Save.

The one page we checked is not set up for phones. They can look broken or zoomed out on mobile, and most of your visitors are on mobile.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd the mobile setting so pages fit phone screens properly.

Your site has no sitemap. A sitemap is a list of your pages that helps Google find them. Without one, new pages can take much longer to show up in search, so you get found more slowly.

One paste into the tool that built your app

What to doAdd a sitemap file that lists your pages, and point to it from your robots file.

The one page we checked has no description, the little summary Google shows under your title. Without it Google writes its own, which usually gets fewer clicks.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd a short description to each page that sums up what it is about.

The one page we checked has no clear main heading. The main heading is how Google works out what the page is about.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doGive each page one clear main heading at the top.

The one page we checked does not say which web address is the main one. Google can then split your ranking across duplicate addresses, so you rank lower than you should.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd the setting that points each page to its main web address.

The one page we checked has no proper share preview (a title, a description, and a preview image). When someone shares your link on WhatsApp or LinkedIn, it shows a blank, unappealing box instead.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd a share preview (a title and image) to each page.

The one page we checked has images with no text description. This hurts you in image search, and blind visitors using a screen reader cannot tell what the image shows.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd a short description to each meaningful image.

The one page we checked has no structured data. This is the extra information that earns rich results in Google, like star ratings or prices, which stand out and get more clicks.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doAdd structured data describing what each page is (a product, an article, a business).

The one page we checked does not say what language it is written in. This helps search engines and translation tools serve the right people.

1 of 1 pages checked have this issue.

One paste into the tool that built your app

What to doSet the page language at the top of each page.

Your pages are almost empty until they run in a browser. AI assistants, and often Google too, read the plain page without running it, so they see nothing. Your content then does not appear in their answers or in search.

One paste into the tool that built your app

What to doMake your main content appear in the page itself, so it can be read without running anything.

Your site has no llms.txt, a simple guide that helps AI assistants understand your site and describe it correctly. Adding one is an easy way to shape how AI talks about you.

One paste into the tool that built your app

What to doAdd an llms.txt file that lists your key pages and what your site is about.