Security

Security Scans

Each site has three scans. You'll find them in the builder under Settings > Security.

Package Scan

Your site is built on open-source packages, like the framework it runs on. The package scan checks every package your site uses against the npm advisory database of known security problems. It runs every day for active and published sites, after the AI builds, and every time you publish, so it reflects what is actually live.

Code Scan

The code scan is automatic and free. It runs on every publish, and any time you start it. It looks for the mistakes that most often expose a site's data:

• Secret keys in code that browsers can see
• Secret values in public environment variables (names starting with NEXT_PUBLIC_), which anyone who opens your site can read
• Service keys, which skip your database's access rules, used in browser code
• Database tables without row level security, which anyone could read or change
• Scheduled-job routes that anyone can call
• Unsafe HTML rendering, which can let someone run their own scripts on your pages
• Image settings that are more open than they need to be

AI Security Review

The AI security review runs in chat when you ask for it, and uses credits like any message. An AI reads all of your site's code and looks for problems specific to how your site works:

• Who can read or change what
• Pages and actions that should check someone is signed in
• Payments
• Injection, where input from a visitor is treated as code or a database query
• Data shown to people who shouldn't see it

Each finding comes with a plain explanation and a suggested fix. Fix with AI applies one.

Severity

Every finding is rated critical, high, moderate or low. Start with critical and high.

What Scans Can't Do

No scanner catches every risk. A clean report means none of these checks found a problem, not that your site has none. Test anything that handles sign-ins, payments or your Users' data before you rely on it.

Automatic Security Updates

When a package your site uses has a critical vulnerability, and the fix is in the same major version, WebTwizz updates your site for you:

• Only package versions change. Your site's own code is never touched.
• We rebuild the published version of your site. Unfinished drafts are never published.
• If the rebuild fails, your current version stays live.
• An undo point is saved in your version history.
• If your project syncs to GitHub, the update is pushed there as a commit.
• You get an email that says what changed.

Automatic updates are on by default for new sites. Sites created before automatic updates existed have them off. You can switch them on or off for any site in Settings > Security. If an issue is being actively exploited, we may apply the update anyway, and may take a site offline until it's fixed. See our Terms of Service.

Some issues need more than a version bump, such as a new major version or a change to your code. We never apply those on our own. They're flagged for you with a one-click fix.

Email Alerts

• Critical issues: when a published site has a new critical issue, its owner gets an email. This is on by default, and you can turn it off in Settings > Security.
• High issues: collected into a weekly digest.

Publish Checks

Every publish runs the package scan and the code scan, and the results show in the publish window.

If you'd rather never publish with a critical issue open, you can block publishing until it's fixed. This is off by default, and you turn it on in Settings > Security.

What WebTwizz Handles

You don't need to do anything for these. We keep them secure and up to date:

• The starter and templates: the starter every new site is built from, and every template in the gallery
• Preview environments: each site's preview runs in its own isolated virtual machine
• Hosting: WebTwizz hosting for sites on webtwizz.app addresses and on their own domains
• Secrets: API keys and other secret values are stored encrypted. You enter them only on WebTwizz, never in a chat with an AI assistant
• Password-protected and private sites: access is checked before the site loads

Response Times

When a package WebTwizz supplies has a known security problem, we fix it within:

• Critical: 72 hours
• High: 14 days

Reporting a Vulnerability

If you find a security problem, email security@webtwizz.com. We'll reply, and keep you updated while we fix it.

What to Include

• What you found, and where: the address, page or feature
• The steps to reproduce it
• What someone could do with it
• How to reach you if we have questions

Scope

The WebTwizz platform, including webtwizz.com, the builder and the dashboard, and sites hosted on WebTwizz, at webtwizz.app addresses or on their own domains.

Safe Harbor

If you research in good faith and follow this page, we won't take legal action against you, and we'll treat your research as authorized. Please:

• Don't access, change or delete other people's data. If you reach someone else's data by accident, stop, don't keep a copy, and tell us
• Test only with accounts and sites you own, or have permission to test
• Don't run tests that slow down or take down WebTwizz or the sites on it
• Give us a reasonable time to fix a problem before you share it publicly

Advisories

Security releases that affected, or could have affected, sites on WebTwizz, and what we did about them.

October 2026: Next.js Security Release

• What it was: fixes for three vulnerabilities in Next.js, two critical and one high
• WebTwizz sites affected: yes, sites on earlier versions of Next.js
• What we did: moved the starter and every gallery template to Next.js 16.4.2, which has the fixes, and updated preview environments. Affected published sites are being updated.

Contact Us

For security reports, email security@webtwizz.com. For anything else: