Anticode Open builder

Checklist

AI website security checklist

AI-generated pages tend to fail in the same places: no Content-Security-Policy, forms posting to unknown endpoints and keys pasted into front-end code. These twelve checks catch the most common problems in the HTML a visitor actually receives. They are the same checks Anticode's Sentinel agent runs on every build.

Updated · By the Anticode team

Before you start

Run these checks on the final HTML, after every edit, not on the prompt or an earlier draft. Use your browser's developer tools: the Elements panel for markup, and the Network panel to see response headers. Where a check depends on a header, a <meta> tag in the page can stand in for a static file, but a real HTTP header is stronger.

Scripts and policy

1. A Content-Security-Policy is set

Why: a CSP tells the browser which sources of scripts, styles, images and connections the page is allowed to use, which limits what an injected tag can do. Check: look for a Content-Security-Policy response header, or a <meta http-equiv="Content-Security-Policy"> tag, with at least a default-src directive.

2. Scripts are blocked by policy

Why: a brochure page, a menu or a booking form rarely needs JavaScript, and a page with no scripts has no client-side code to exploit. Check: the policy contains script-src 'none' and the page contains no <script> tags. If your page genuinely needs scripts, allow only your own origin and avoid 'unsafe-inline'.

3. No inline event handlers

Why: attributes such as onclick and onload are inline scripts, so they defeat a strict policy and are a common injection target. Check: search the source for on followed by an event name inside a tag. There should be none.

Forms

4. Text fields are typed and length-capped

Why: a type gives visitors the right keyboard and basic validation, and a maxlength stops someone pasting megabytes into your inbox. Check: every <input> has a type and a maxlength, and every <textarea> has a maxlength. Validate again on the server, since browser limits are easy to bypass.

5. Every field has a label

Why: a field without a label is unusable with a screen reader, and placeholder text disappears as soon as someone types. Check: each field is inside a <label>, is referenced by a <label for>, or has an aria-label.

6. Forms post to your own origin

Why: generated forms sometimes post to a placeholder service, a third-party form host or nowhere at all, which can leak personal data or silently drop it. Check: every <form> uses method="post" and an action that is a path on your own site, and no button overrides it with formaction.

7. Form targets are locked down

Why: even if the markup is right today, a later edit or an injected form could post elsewhere. Check: the policy includes form-action 'self'.

Why: a link opened with target="_blank" can otherwise give the new page a handle on yours. Modern browsers imply noopener, but setting it explicitly protects older ones. Check: every target="_blank" link has rel="noopener", usually with noreferrer.

9. No keys or tokens in the page

Why: anything in the HTML is public. Pasted API keys are one of the most common and most expensive mistakes in AI-built sites. Check: search the source for patterns such as sk-, sk_live_, pk_live_, AKIA, api_key and Bearer. If you find a real key, revoke it first, then remove it.

10. Every URL uses HTTPS

Why: an http:// image, script or form target on an HTTPS page is mixed content: browsers block or warn about it, and it can be tampered with in transit. Check: no src, href or action starts with http://.

11. A referrer policy is set

Why: without one, full URLs, including query strings that may hold identifiers, can be sent to other sites. Check: a Referrer-Policy header or a <meta name="referrer"> tag, such as strict-origin-when-cross-origin.

12. Every image has a text alternative

Why: this is an accessibility requirement rather than a security one, and it's on the list because it's checked on the same final HTML and missed just as often. Check: every <img> has an alt attribute that describes it, or an empty alt if it's purely decorative.

What this checklist doesn't cover

These checks look at the page a visitor receives. They don't review the server behind it. If your site has accounts, payments or a database, you also need:

  • Server-side validation of every field, regardless of what the browser enforces.
  • Authentication with rate limits on sign-in, and authorisation checks on every request that reads or changes data.
  • Secrets stored as server environment variables, never in the repository.
  • Protection against cross-site request forgery for any request that changes state.
  • Dependency updates and a way to hear about vulnerabilities in what you use.

The OWASP Top 10 is a good next step for the server side. Anticode's Next.js export ships with several of these protections built in, including server routes for every form, role-based access and two-factor sign-in for admins; see how Anticode works.