How We Secure Our Own Work

The site is static files on a content delivery network. There is no content management system, no database, no admin login and no server process to patch. The one piece of code that runs on request handles the engagement form: it checks the request origin, caps the body size, validates every field, verifies a challenge token and rate limits by address. Nothing it receives is stored anywhere except the email it sends.

Every page ships with a Content Security Policy that allows no inline scripts and no eval, with frame-ancestors none, base-uri none and object-src none. A check runs on every build and fails it if a page would need an exception. There is no analytics script, no chat widget, no third-party font and no embedded third-party form, because each of those would weaken the policy.

Transport is TLS 1.2 or better with HSTS, the domain publishes SPF, DKIM and DMARC, and a security.txt names the address for reports. Monthly header and TLS scans are recorded in the repository so the posture is measured, not assumed.

Each tool under /tools/ runs in your browser. Its page states what it does, exactly what it sends over the network and to which host, and what it stores. Three of the four say No network: nothing you enter leaves the tab. The one that looks up DNS records names the resolver it queries and what it sends, and nothing else is sent.

Tool input is treated as data. The code never evaluates it and never writes it into the page as markup. Inputs have length limits and results are built as text.

Our tools observe and report by default. A tool only probes a live system when you have placed that system in scope yourself, and an active check always asks for a confirmation that software cannot answer on your behalf. Where a check can prove a condition without triggering the bug, it does, the way our PHP checker does.

Every module gets a threat model before code. Anything that parses untrusted input is fuzz tested. Secrets never appear in logs. When we fix a bug class in one place, we sweep the rest of the codebase for the same class before the fix ships.

Releases are signed and their hashes are published on the product page, together with every permission the software needs and every network connection it makes. A release is not finished until its page shows the version, the release notes and a demo recorded against a lab target, never a customer system.

Every change passes a security review and then a performance review before it merges, and platform releases get a final sign-off. Once the products earn revenue, an outside firm reviews the platform, because a security firm checking its own work is not an independent check.

If you find a security issue in anything we publish or run, write to security@atarussecurity.com. We answer within two business days, keep you informed, and credit you if you want credit. Test only what you are authorized to test, keep no data that is not yours and do not degrade the service for others. Our coordinated disclosure policy describes how we treat vendors; we hold ourselves to the same timeline.