Trust Center
How this platform handles your security data.
A security product that asks you to point it at your infrastructure owes you a straight answer about its own. These documents describe what is actually implemented in this codebase — including a plainly-listed set of limitations, because a trust page that only lists strengths is not one.
Security practices
Passwords are never stored
Account passwords are hashed with scrypt using a per-user salt and compared in constant time. The plaintext is never written to disk or logs.
Sessions store only a hash
A session is a random 256-bit token delivered in an httpOnly, SameSite=Lax cookie. The server keeps only its SHA-256 hash and an expiry, so a database read cannot recover a live session token.
Scan data stays in this deployment
Findings, scan history, and audit entries are written to this deployment's own database — no third-party backend receives them, and export and deletion are self-service.
Outbound calls are enumerated, not vague
The Privacy Policy names every external service a scan can contact and exactly what is sent to each. There is no analytics or advertising tracking anywhere in the application.
Webhooks are SSRF-guarded
A webhook destination is rejected if it resolves to a private, loopback, link-local, or CGNAT address — including the cloud metadata endpoint — checked when saved and again immediately before every delivery.
The audit log is tamper-evident
Each entry hashes its own contents together with the previous entry's hash. Editing or deleting a past entry breaks the chain from that point forward, and the break is detectable on demand.
Active scanning requires proven ownership
Checks that go beyond a normal browser visit stay locked until domain ownership is proven with a real DNS TXT record or a well-known file served from the target.
Secrets are masked before storage
When the scanner matches a credential pattern, the value is masked down to a few leading and trailing characters before it is ever stored or displayed.
The Security Policy documents each of these in technical detail, alongside the limitations that are not solved yet.
Documents
Trust
Policies
- Acceptable Use PolicyWhat you may and may not point the scanners at.
- Privacy PolicyWhat data is stored, where it lives, and every third party it is sent to.
- Cookie PolicyEvery cookie and browser-storage key this application sets, and why.
- Security Testing AuthorizationWhich checks run against any target, which require proven ownership, and which this product refuses to build.
- AI Usage PolicyThis product analyses AI systems without using one. What that means, and the limits on the red-team suite.
- Data Retention & DeletionHow long data is kept, what deletion removes, and what it deliberately does not.
- Data Processing & SubprocessorsEvery third party your deployment sends data to, derived from the code rather than a vendor list.
Data protection contact
For any question, request, or complaint about personal data — access, correction, erasure, or how any of it is handled. You do not need a reason or a form.
- Contact
- Mayank Jain
- privacy@webcuris.com
- Established in
- India
Full detail, including how to escalate to a regulator, is in the Privacy Policy.
What this platform does not claim
Stating these explicitly is part of the point. This application holds no security certifications — it has not been through a SOC 2 audit, an ISO 27001 certification, or a third-party penetration test. The compliance mappings in the product are our own best-effort associations from a finding's CWE to a published control, offered as situational context; they are not official crosswalks and never indicate that a control is implemented, satisfied, or audited. A clean scan is not a certification of security, and this tool is not a substitute for a penetration test or a professional security audit.