--- title: "A Website That Is Safe by Default | Briks" url: https://briks.dev/features/safe-by-default description: "Code read for security before every publish, keys cut out of messages and kept only on your site, visitors counted without cookies, and every version kept." last_updated: 2026-10-08 --- On every plan # Safe by default, on every site Safe by default describes how every Briks site is built and hosted, on every plan, with nothing to switch on. Its code is read for security before each publish, its keys stay out of messages and pages, it runs apart from every other site, it counts visitors without cookies, and every version is kept so any change can be undone. ## How it works 1. **Read before every publish** The code written for your site is checked for the mistakes that most often leak data. 2. **Keys kept out of sight** A key pasted into a message is cut out, and its value lives only in your site's Secrets. 3. **Every version kept** Undo any change, and on a paid plan keep a copy of your records every night. ## Your site's code is read before every publish Before a site publishes, Briks reads the code written for it for the mistakes that most often leak data, and sends what it finds back to the builder to fix. The read looks for keys and passwords written into files, routes that change data with no limit on how often, members' records read without checking who is asking, database queries built by joining strings, HTML set from raw text, and calls to other addresses. These checks are Briks's own rules, read from the files the same way every time, with no AI model and no credits. Colour contrast is checked too, in the code and on the live page. On a paid plan, the Security agent goes further: it checks the code after every publish and the live site every week, explains each finding in plain words, and asks you before any fix. ## Keys stay out of messages and pages Paste a key into a request by mistake and it is cut out before the message is kept or read by any AI model. The reply says the key was removed, and where it belongs instead: Settings → Secrets. When a change needs a key, the studio asks for it with a field that saves straight to Secrets. The value is kept only with your published site, where your site's code reads it behind its routes. Visitors' browsers never receive it, the code you download leaves it out, and once saved it is never shown again to anyone, you included. ## Each site runs apart Every site is published on its own: its own server code, its own database for the records it keeps, and its own file storage, made in the EU by default. A site's keys are bound to that site alone. Agents follow the same rule. Each sees only its own workspace, enforced in the database itself, so an agent working on one client's site can never read another's. ## Visitors counted without cookies Analytics on every site sets no cookies, keeps nothing on the visitor's device and stores no address, and figures are kept for 25 months. It is designed to need no consent banner in most countries, and you can switch it off for any site. Other things on a site may still need a notice, such as an A/B test, which keeps each visitor in their version with a cookie, or anything embedded from another service. ## Every version kept, and your records too Every build, change and recheck is saved as a version. Anyone with edit rights can undo, redo or restore one, and the site is published again as it was. Your database keeps its own history, so Owners and Admins can take it back to any minute within it, or to a restore point you named. On a paid plan, nightly copies keep a full copy of your records for 30 days, and you can download your records at any time. ## Safe by default in practice Three example businesses, and how each would use it. Where a site is pictured, it is a sample Briks built for an example business, not a customer. 1. Yoga studio **A key pasted into the chat** A yoga studio's owner pastes her booking service's key into the studio chat with her request. The key is cut out before the message is kept, the reply asks her to add it in Settings → Secrets, and the change carries on once it is there. 2. Bakery **A Friday change, undone on Saturday** A bakery's new menu section crowds the page on phones. On Saturday morning the owner restores the version from before it, and the site is published again as it was while she asks for a better layout. [![The opening of Sourdough, a sample site Briks built for an example bakery and coffee shop](https://briks.dev/showcase/sourdough.webp)](https://sourdough.briks.live/) **Sourdough** is a sample site Briks built for an example bakery and coffee shop, not a customer. [Open the sample](https://sourdough.briks.live/) 3. Psychology practice **Visitor numbers without a cookie banner** A psychology practice wants to know how people find it without asking every visitor about cookies. Its site counts visits without cookies from the first publish, and when Briks writes its privacy page, the page gives visitors a way to opt out. ## What you get - Code read for security before every publish - Pasted keys cut out of messages - Key values kept only on your published site - Its own database and storage for each site - Analytics without cookies - Every version kept, with undo - Nightly database copies on paid plans ## Questions about safe by default ### Do I need to set anything up? No. The checks before publishing, keys kept out of messages, counting without cookies and versions come with every site. Nightly copies are switched on in the Database tab, on a paid plan. ### What happens if I paste a key into the chat? It is cut out before the message is kept or read, and the reply tells you to add it in Settings → Secrets. ### Can anyone see a secret once it is saved? No one, you included. The studio keeps only its name, who saved it and when; the value lives on your published site. ### Is my site checked after it goes live? On a paid plan, hire the Security agent. It checks your code after every publish and the live site every Monday, and asks before any fix. ### Can I undo a change? Yes. Every build and change is a version that anyone with edit rights can undo, redo or restore. ## Related features - [Paid plans **Security agent** The Security agent checks your site's code after every publish and the live site weekly, explains each finding in plain words, and fixes only what you approve. How it works](https://briks.dev/features/security-agent) - [On every plan **Versions and undo** Every Briks build and change is saved as a version. Undo, redo or restore any of them from the studio, and the site is published again as it was. How it works](https://briks.dev/features/versions-and-undo) - [On every plan **Analytics without cookies** Every Briks site counts visitors without cookies. Ask about your visits in plain words, set goals, see where people stop, and count visits from AI assistants. How it works](https://briks.dev/features/analytics) - [Paid plans **Nightly database copies** On a paid plan, switch on nightly copies and Briks copies your site's database every night and keeps each copy for 30 days, so you can go back after a mistake. How it works](https://briks.dev/features/nightly-copies) [See all 32 features](https://briks.dev/features) ## Try it on your own business Describe it in a sentence and Briks builds it. Start free with the credits you get at sign-up.