AI is now writing a surprising amount of front-end code. Useful, fast, sometimes spooky. But regulated teams know speed without safety is a liability. This guide gives you a workable path to secure AI code in the browser: policies that don’t suffocate developers, review workflows that actually catch risk, and compliance evidence you can hand auditors without sweating through your hoodie.
What problem are we actually solving with secure AI code?
Front-end AI generation adds two risk buckets: content safety and supply chain. On the content side, large models tend to output convenience patterns that break basic web hygiene: innerHTML with user data, weak input validation, missing CSP headers, relaxed iframe sandboxing. That’s how you invite XSS, clickjacking, token leakage, even subtle UX phishing.
On the supply chain side, the AI happily pulls in packages or snippets with licenses you can’t touch in finance or healthcare, or with post-install scripts that mine your CI minutes. Not ideal.
Here’s the gist: secure AI code means the UI the model writes is hardened against XSS and data leaks, the dependencies are vetted, and the provenance is auditable.
Plain English takeaway: treat AI as a junior contractor with infinite energy and zero context.
What policies make AI-generated front-end code safe?
Write a short AI usage policy that maps to your SDLC. Three to five pages, not a novel.
Require:
- Disclosure of AI assistance in PRs
- Approved models and settings (for example, GPT-4o-mini temperature 0.2 for code)
- Banned patterns list (
dangerouslySetInnerHTML,eval,new Function,blob:without CSP,fetchto wildcard domains) - Minimum sandbox rules for iframes
- CSP baseline (
script-src 'self'plus nonce, disallow inline without Trusted Types) - Code provenance fields captured at PR time
Said bluntly: bake guardrails into culture and tooling so it’s easier to do the secure thing.
Licensing policy matters too. Force the model to avoid GPL-only snippets in front-end artifacts that ship to browsers. Your policy should state: permissive only for shipped JS/CSS (MIT, Apache-2.0, BSD-3). Use a scanner like FOSSA or Snyk License to enforce and gate on build.
Quick restatement: no unknown licenses in the bundle, ever.
How do we prove code provenance end to end?
Auditors and security leads are asking where code came from. Build an audit trail with three layers: source control, build attestation, and artifact SBOM.
In GitHub or GitLab, require a PR template with fields: Model, Version, Prompt file link, Temperature, Tools enabled. Store prompts as artifacts or in a prompts/ directory. Add a commit trailer like Co-authored-by: AI Assistant to make queries easy. One big bank client adds git notes tying PRs to ticket IDs and prompt hashes (we argued on Slack at midnight about commas in the schema).
For builds, sign artifacts using Sigstore or GitHub’s OIDC-based attestations. Aim for SLSA level 2 minimum this quarter, level 3 next. Generate a front-end SBOM with CycloneDX including npm deps and their integrity hashes; attach it to the release.
Shortcut version: tag where the code came from, sign what you built, list what’s inside. When a regulator asks, you can produce an evidence pack in under 2 hours.
What review workflows actually catch issues, not just look busy?
Layer checks early, cheap, and human-verified.
Pre-commit: ESLint with security plugins, TypeScript strict, Semgrep rules for DOM sinks, and a linter rule that blocks innerHTML unless sanitized.
CI step 1: dependency scanning and license check; block on any unknown license or critical CVE.
CI step 2: SAST with CodeQL or Semgrep CI; flag Trusted Types violations, CSP relaxations, and unsafe React operations.
CI step 3: UI security tests. Yes, tests. Write unit tests that assert DOMPurify or a sanitizer runs before dangerous sinks. Add a quick Playwright run that loads an untrusted string containing <script> into common components and asserts no execution. We once caught a regression in a wizard step that only rendered after the third click. Fun day.
Branch protections should require two human approvals for code that touches src/components or public/index.html. No bot self-merge. Require an ephemeral preview environment with CSP, Subresource Integrity, and tracking disabled for review. Add ZAP baseline or Burp’s automation against the preview.
Track a few numbers: 100 percent of AI-assisted PRs must include model metadata; 95 percent of PRs need at least one security-tagged comment; target zero CSP unsafe-inline exceptions in shipped code.
Plain English: checks that run without humans are necessary, but humans still catch the weird stuff.
How does compliance map to the code itself?
Standards have words for this. NIST SSDF SP 800-218 wants you to define, implement, and verify secure development practices. SOC 2 CC8 expects change management with approvals and traceability. ISO 27001 Annex A.14 calls out secure change control. PCI DSS 6.5 lists common vulnerabilities like XSS you must address.
Translate that into artifacts: your AI policy doc, PR templates with AI fields, SBOM and attestations per release, evidence of code review with names and timestamps, and test outputs from SAST and DAST. Keep them in the same place you store incident reviews.
Auditors love consistent evidence. One healthcare client packaged quarterly samples: five AI-assisted PRs, each with prompt, model version, review comments, test outputs, and a screenshot of the preview CSP report. They passed with a light note about improving license scanning depth.
So what does this mean? Tie compliance to the artifacts your developers already produce, not a separate spreadsheet farm.
What about the weird stuff: prompts, plugins, and UI SDKs?
Prompts can be attack surfaces. If your plug-ins or repo context include vulnerable patterns, the model will parrot them. Maintain a prompt library with safe snippets for forms, sanitization, and CSP headers. Include comments like Do not use innerHTML, use createTextNode or setTextContent. We tried letting prompts drift for a month, and the less said about that week, the better.
Third-party SDKs and tags are front-door risk. Enforce an allowlist for analytics and widgets. Use CSP with strict script nonces and disallow unsafe-eval. Add Subresource Integrity for CDNs. If you’re stuck with a vendor that requires unsafe-inline, negotiate or isolate them in a sandboxed iframe with allow-scripts but no same-origin. Consent management needs to gate those scripts. Consider Trusted Types in Chrome and Firefox’s CSP strict-dynamic.
Restated: if it runs in your page, you own it, even if AI pasted it in.
Q: Should we block AI-generated code outright?
A: No. Block unsupervised AI merges. Allow AI as a drafting tool with policy, tests, and gated reviews. Treat it like pair programming with a brilliant but risk-blind partner.
Q: What metrics prove this works?
A: Track time-to-merge for AI-assisted PRs vs human-only, escaped XSS bugs per quarter, CSP violation rate per 10k sessions, percentage of PRs with complete provenance fields, and audit pack readiness time. If the first two stay flat and the last three improve, you’re winning.
Key takeaways
- Provenance first: tag model, prompt, and sign builds
- Front-end hygiene: CSP, Trusted Types, DOMPurify, no
innerHTML - Reviews that bite: two humans, SAST, DAST, UI security tests
- Compliance as artifacts, not theater: SBOM, approvals, evidence pack
- Vendors on a leash: allowlist, SRI, sandbox or eject
Action checklist
1. Policy and documentation
- Publish a concise 3-page AI code policy listing banned patterns and approved models.
- Add PR templates that capture model name, prompt, reviewers, and provenance fields.
2. Static and pre-commit safeguards
- Enforce ESLint security rules, Semgrep checks, and TypeScript strict mode at pre-commit.
- Block builds automatically on license or CVE scan failures.
3. Front-end hardening
- Enable Trusted Types and a strong Content Security Policy (
script-src 'self'plus nonce). - Apply Subresource Integrity (SRI) to all CDN scripts in both preview and production builds.
- Require sanitization with DOMPurify or equivalent before rendering user content.
4. Testing and reviews
- Write a Playwright XSS smoke test that injects
<script>strings into common components. - Require two human approvals on UI-related paths; prohibit bot self-merges.
- Run SAST (CodeQL/Semgrep) and DAST (ZAP/Burp) in CI for every preview environment.
5. Provenance and signing
- Sign artifacts with Sigstore and attach a CycloneDX SBOM to each release.
- Store prompts, review comments, and test outputs together with tagged releases.
6. Vendor and SDK governance
- Review vendors quarterly and enforce an allowlist for analytics and SDKs.
- Isolate risky third-party scripts in sandboxed iframes with
allow-scriptsbut nosame-origin.
7. Monitoring and metrics
- Track escaped XSS bugs per quarter and CSP violation rate per 10k sessions.
- Measure audit pack readiness time (target under 2 hours).
- Review false positives and triage data monthly to refine AI-generated code workflows.
Why it matters:
Each control reinforces another, policy defines intent, automation enforces it, and evidence closes the loop. Together they make AI-assisted development fast, compliant, and reviewable without draining velocity.
We still screw this up sometimes, but it beats shipping a font-blocking CSP that takes down Sydney for 48 hours.
Discover what the future of frontend development looks like!
