Security review for AI-built websites and apps

Working is not the same as secure

An AI-assisted application can look polished and pass a happy-path demonstration while still allowing unauthorised access. Treat generated code as code that needs review, not as evidence that security requirements have been met. The same applies to changes produced after launch.

Follow one sensitive journey

Choose a journey such as downloading a customer report. Follow it from the page to the server, database and file storage. Ask where the caller is identified, where ownership is checked, and what happens when a different user requests the same record.

Before going live

Review the deployed settings as well as the source. Development defaults and demo accounts can create risks that are not visible on the public page.

• Keep private credentials out of browser code and repositories
• Require server-side permission checks for sensitive reads and writes
• Review public file storage and share links
• Remove demo accounts and debugging output
• Check third-party packages and maintain a patch process

Review each generated change

Ask for a small change with a clear acceptance check. Inspect whether it weakens an existing permission rule or adds another path to the same data. Tests should include another user and a signed-out request, not just the account that owns the record.

Agree an assessment scope

List the live application addresses, sensitive features and user roles. Use synthetic accounts where possible and obtain written authorisation before testing. A focused assessment is a useful first look, while a full manual test can explore more complex workflows under an agreed scope.