Security Guide for AI-Built Websites

Start with the real risk

A public information site, an enquiry form and an authenticated application need different controls. Identify what the system exposes, what information it handles, who should have access and what would matter if a service failed.

During production-readiness reviews, we commonly find sensible prototype shortcuts that no longer match the intended audience. The goal is to replace those shortcuts proportionately, not to add complexity for its own sake.

• List public and private functions.
• Identify personal, business-sensitive and operational information.
• Map the systems and providers that receive data.
• Prioritise risks by likelihood and consequence.

Public configuration, environment variables and secrets

Code sent to a browser can be inspected. A variable's name does not make its value private, and a static export cannot safely contain a server credential.

Store secrets in protected provider configuration and make them available only to the server-side function that needs them. Document variable names and purpose separately from their values. If a secret enters source control, revoke or rotate it; deleting the latest line is not enough.

Authentication, authorisation and least privilege

Authentication answers who someone is. Authorisation answers what that person is allowed to do. A logged-in user should not gain access merely by changing a URL or request value.

Give people, deployment workflows and services only the access they need. Use separate roles, multi-factor authentication and business-controlled recovery methods where providers support them. Remove access when a role ends.

• Protect administrative functions with server-enforced checks.
• Test access using more than one user role.
• Avoid shared owner credentials.
• Limit service permissions and deployment scopes.
• Review access periodically and after handover.

Input validation and contact-form abuse

Browser validation improves usability but cannot be trusted as a security boundary. The server must enforce required fields, length limits, formats and allowed values.

Public forms attract automation. Apply proportionate rate controls, a bot-detection approach where justified, safe provider limits and generic failure messages. Minimise the information collected and never write submitted messages into analytics.

Dependencies, security headers and HTTPS

Every dependency adds code and a maintenance relationship. Keep packages purposeful, review updates and vulnerability reports in context, and remove unused libraries.

Security headers can limit browser behaviour such as framing, resource loading and information leakage. Configure them against the site's real integrations and test them; an overly broad or overly strict policy can both create problems.

HTTPS protects traffic between the browser and the service. Verify valid certificates and redirects on every public hostname. It does not replace validation, access control or safe storage.

• Use a supported runtime and maintained dependencies.
• Review changes before automatic updates reach production.
• Set headers at the platform layer where appropriate.
• Avoid revealing unnecessary framework information.
• Test certificates, redirects and mixed-content behaviour.

Log safely and prepare for recovery

Logs should help answer operational questions without becoming a second store of personal or secret information. Record generic event types, status and necessary identifiers; exclude passwords, tokens, message bodies and full sensitive URLs.

Backups and recovery are security controls because deletion, account loss and malicious change can affect availability and integrity. Keep recoverable copies outside the failure boundary they protect and test a meaningful restore.

• Define what is logged and who can access it.
• Set retention appropriate to the operational need.
• Alert on material failures without including sensitive payloads.
• Back up source and essential configuration records.
• Document account recovery and incident contacts.
• Test restoration and rollback before relying on them.

Responsible limitations

No checklist proves that a site is free from every vulnerability. Security is an ongoing risk-management process shaped by the system, data, providers and threat environment.

A production review helps identify common and material risks. Specialist penetration testing, legal advice, compliance assessment or independent certification are separate services and should never be implied without evidence.