No scripts at all: why Anticode pages ship without JavaScript
Pages from Anticode's design engine contain no script tags, and their policy says script-src 'none', so a browser won't run JavaScript on them even if some found its way in. Sentinel checks both halves in the builder, and the server refuses to publish a page carrying scripts, frames or plugins. It's a deliberate constraint: a website with no JavaScript has very little for an attacker to work with.
What removing script takes off the table
Most serious attacks on an ordinary website need code running in the visitor's browser. Cross-site scripting injects a script through a form or a URL. A compromised analytics or chat widget ships malicious code to every visitor. A card-skimming script copies what people type into a checkout. Each of these depends on the page being willing to run JavaScript from somewhere. A page with no scripts, and a policy that forbids them, closes that whole category at once rather than defending against each attack separately.
There's a performance side too. With no scripts to download, parse and run, the page is ready as soon as its HTML, styles and fonts arrive, and there's nothing to block a phone's main thread.
How it's enforced, twice
| Where | What it checks |
|---|---|
| Sentinel, in the builder | The page's policy includes script-src 'none' and the page contains no script element. Shown in the Report tab as “Scripts are blocked by policy”. |
| The server, at publish | No script, iframe, frame, frameset, object, embed, applet, base or portal element; no meta refresh redirect; no link that imports or preloads script. It also scans the raw text for a script tag as a second net. |
| The published response | The site's own policy header also forbids scripts, frames and plugins, so even a page that slipped past both checks couldn't run code. |
The server check exists because the builder runs in your browser, and a modified browser could skip it. The publish gate doesn't depend on what the browser claims. If a page fails, publishing stops with a message naming “no scripts, frames or plugins” and the element it found. The code editor in Pro mode refuses a script tag before anything is applied, with a note that pages ship with script-src 'none'.
What still works without JavaScript
More than people expect. HTML and CSS handle the things most small business sites need:
- Navigation and multi-page sites: plain links, including anchors that jump to sections.
- Forms: contact, booking, newsletter and custom forms post to the site's own server, which validates, stores the submission and returns a thank-you page in the site's design.
- The booking calendar: days and times are real radio buttons styled as slots, so picking one needs no script.
- FAQ sections: questions open and close with the built-in
detailsandsummaryelements. - Calculated answers: a site function can work out a quote on the server and show it on the thank-you page.
- Motion: CSS animations, and scroll-linked effects in browsers that support scroll-driven animation.
- Buy buttons: a link to a checkout from the owner's payment provider.
What it rules out
The same rule that keeps the page safe also limits it, and it's better to know before you build:
- No embeds. YouTube, Spotify, maps and third-party booking widgets need frames or scripts. Link to them instead.
- Nothing live as you type. A quote total appears after the form is sent, not while the visitor fills it in; see formula functions.
- No third-party trackers or chat widgets. Anticode's own analytics are counted on the server without them.
- No hand-added scripts. The code editor won't keep one, and publishing would refuse it.
When you genuinely need interactivity, such as a calculator that updates live, a game or a configurator, that's what Anticode's app builds are for. They run their own JavaScript inside a strict sandbox with no network access; see the app sandbox. For a full application with its own server, the Next.js export gives you the code.
Limits
- Scripts aren't the only risk. A page can still link somewhere harmful or leak data through a careless form. Sentinel's other checks cover those.
- Design-engine pages only. App builds run scripts by design and are checked by their own code gate instead.
Questions people ask
Can a website with no JavaScript take bookings and enquiries?
Yes. Forms are plain HTML posts to the site's server, which stores them and shows a thank-you page. The booking calendar uses styled radio buttons.
Can I add Google Analytics or a chat widget?
No. Both need scripts, which the page's policy forbids. Anticode's own analytics count views on the server instead.
Why does the server check for scripts again at publish?
Because the builder's checks run in your browser, which could be modified. The server's check can't be skipped that way.