Is an AI-built website safe? A 10-point checklist before launch
What BrewInTH secures for you, ten checks for the app, a prompt that makes the AI review its own code, and five tests to run yourself before launch.
An AI can finish a website in an hour. It looks good and the buttons work. But "works" and "safe" are different things: a site that behaves normally may still let a stranger read your customers' data, or spend money through your API key, with nothing odd on the screen.
This guide answers how safe an AI-built site is, what BrewInTH already takes care of, and what you and your AI must do yourselves, with a ten-point checklist, a prompt that makes the AI review its own code, and five simple tests that need no coding.
In short
✅ An AI-built site can be safe when you ask clearly and check before launch; left alone, an AI gets it "working" first and skips permissions and secrets
✅ BrewInTH covers the infrastructure layer: HTTPS on every site, projects isolated from each other, encrypted app settings and request rate limits
✅ The app layer is yours and your AI's: sign-in, permissions, input checks and where secrets live
✅ The most common holes: seeing someone else's data by changing a number in the address, and an API key that ends up inside the web page
✅ A site that takes payments or holds health data or a lot of personal data deserves an expert review before launch
Is an AI-built website safe?
The honest answer: it depends on what you ask for and what you check. An AI knows how to write safe code, but when the brief is "make it work" it takes the shortest road. The problems that keep turning up are few:
- a button hidden from users without permission, with no check on the server;
- an API key in the page's code, where anyone can read it;
- a test account such as admin / admin123 left behind;
- debug mode left on, so error pages show internal details;
- file uploads that accept any type and any size.
The good news is that every one of them is fixed by telling the AI clearly and checking again before launch.
What BrewInTH handles, and what is yours
What the platform already does
- HTTPS on every site, on the BrewInTH address and on your own domain. Certificates are issued for you; there is nothing to configure.
- Each project runs apart from the others. Your app has its own space and is not mixed with other customers'.
- App settings (secrets) are encrypted and handed to the app as environment variables when it starts, so they never need to be written in the code.
- Requests are rate-limited per IP at the front, which blunts simple floods.
- AI tokens expire and can be revoked from the console at any time.
- Backups are an add-on that copies the database automatically every day.
What the platform cannot do for you
The platform does not know who should see what inside your app, which data is confidential, or what each form should accept. All of that lives in the code the AI wrote, so it is your job and the AI's.
Ten checks before people use the site
- No secrets in the code or in the page. API keys, database passwords and payment keys belong on the project's App settings tab and are used on the server only. Anything in the page's JavaScript is public.
- Passwords are hashed with a standard method such as bcrypt or argon2, never stored as plain text.
- Permissions are checked on the server on every request: both "is this person signed in?" and "does this record belong to them?".
- Every input is validated on the server, and database commands use parameters instead of glued-together text (this prevents SQL injection).
- Text from users is escaped when shown, so a script someone typed cannot run on the page (this prevents XSS).
- Uploads are limited by type and size, renamed by the app, and kept in persistent storage or an outside file store.
- Repeated failed sign-ins are slowed down, and forms that send email or SMS have a limit.
- No test accounts or default passwords remain, and the admin pages always require sign-in.
- Debug mode is off. Error pages shown to users reveal no code, paths or database commands (Laravel:
APP_DEBUG=false). - Back up, and keep only the personal data you need. Have a privacy policy page if you store user data.
A prompt that makes the AI review its own code
Send this in the same chat where the AI built the site, before anyone uses it:
Before this site goes live, review the security of the whole project and report as a table: item / pass or fail / files involved / fix.
1. Is any secret (API key, password, token) written in the code or sent to the browser?
2. Are user passwords hashed with bcrypt or argon2?
3. Does every route that needs sign-in check it on the server, and check that the record belongs to that user (assume the user changes the id in the request)?
4. Does every database command use parameters? Is user text concatenated anywhere?
5. Is user text escaped before it is displayed?
6. Are file uploads limited by type and size?
7. Are sign-in and forms that send email rate-limited?
8. Are there test accounts, default passwords or debug routes left?
9. Do production error pages reveal internal details?
10. Does any dependency have a known vulnerability (run the audit tool of the language)?
Fix every failed item, say briefly what changed, then deploy to BrewInTH again.
Never print real secret values in the chat or the logs.If you have a second AI, let it review the first one's code with the same prompt. It often spots what the author missed.
Five tests you can do yourself, no code needed
- Change the number in the address. Signed in, open something of yours, such as
/orders/15, then try/orders/14. Someone else's data must not appear. - Open the back office without signing in. In a private window, type the address of the admin page. You must land on the sign-in page.
- Search the page for secrets. Right-click, view the page source and search for
key,secret,token,password. No real value may be there. - Type a script into a form. Enter
<script>alert(1)</script>as a name or a message, save, and open the page that shows it. You must see plain text, and no box pops up. - Cause an error. Open an address that does not exist, or put letters in a number field. The error page must be short and show no code or table names.
Whatever fails, copy what you saw to the AI, have it fixed and test again. Only ever test your own site.
When to bring in an expert
This checklist lowers the common risks. It is not a security certificate. Have an expert review the site when it:
- takes payments or stores card data (better: use the payment provider's hosted page and never store card numbers);
- stores health, financial or identity documents;
- has many users, or runs something the business cannot be without.
Watch the video
▶ From creating a project to a live site (1:30, in Thai)
Watch on YouTube
FAQ
Does a static site with no sign-in need to worry?
Very little. A static site has no database and no server-side program. One thing to check: put no API key or private information in the files, because every file can be read.
The site has HTTPS, so it is safe?
No. HTTPS protects data on the way between the visitor and the site. It does nothing about holes in the app, such as being able to view another person's data.
How long should an AI hold the project token?
As long as the job needs. A token from the automatic link button lasts 24 hours. If the work ends sooner, revoke it on the AI connections page, and never post a token in public.
An API key has leaked. What now?
Revoke that key at the provider right away and issue a new one. Put the new value on the App settings tab, publish again, and have the AI move the call to the server side. Deleting the key from the code is not enough: someone has already seen it.
Do I need to follow the PDPA?
If the site stores personal data such as names, phone numbers or emails, tell users what you collect and why, and keep only what you need. For the legal details ask someone qualified; this article is not legal advice.
Summary
An AI-built site can be safe as long as you do not stop at "it works". Let the platform take the infrastructure layer. For the app layer, go through the ten checks, make the AI review its own code, and run the five tests yourself before you send anyone the link.
Start your first project free →