What is actually in place.
A security page that lists aspirations is worse than none. These are controls the system implements; the section at the bottom is what it does not have.
Working draft. The controls described are implemented. The page has not been through a formal review and should not be treated as a security attestation.
Controls
SSRF protection on the scan endpoint
The public scanner takes a URL from a stranger and causes a fetch, which makes it a request-forgery surface by construction. Submitted hosts are resolved and checked before anything is fetched, and addresses in private space are rejected. The CAPTCHA check runs before validation specifically so the endpoint cannot be used as an unauthenticated probe for whether a hostname resolves internally: the rejection reasons would otherwise differ and leak that.
Abuse controls on the free tier
In the order they matter: Turnstile, which fails closed once enabled so an outage at Cloudflare is not a bypass; a per-domain cooldown, which survives IP rotation because a free scan attaches to a domain rather than a visitor; and a per-caller rate limit, which is deliberately not the main defence because VPNs defeat it and office NAT makes it punish real users.
Credential and token handling
Email verification tokens are stored hashed, not raw: the column is reachable from an unauthenticated surface, and a raw token there would be the link itself. Requester addresses are stored as truncated keyed HMACs rather than in the clear.
Access scoping
Repository and CMS access is limited to the scopes you grant and is not retained beyond them. Revoking access removes the associated data.
Audit logging
Requests are logged through middleware into a queue and written in batches, so the audit trail does not depend on the request path succeeding.
Transport and isolation
TLS in transit. Database access runs through a connection pooler with read-replica support; caches and queues are separated by function rather than sharing one instance.
How the crawler behaves
Relevant if you are assessing us as a third party pointing traffic at your infrastructure.
- Identifies itself as CrawldBot with a URL in the user agent
- Obeys robots.txt, including crawl-delay
- One request at a time: never parallel
- 12 pages per site on competitor monitoring, once a week
- Never submits forms and never attempts authenticated areas
Full detail, including how to block it, is on the crawler page.
Reporting a vulnerability
Report it to us directly before disclosing it publicly, and we will not pursue you for good-faith research conducted against your own account and without degrading service for others.
We are particularly interested in anything touching the unauthenticated scan surface (the SSRF guard, the CAPTCHA path, the share-link and email-gate logic) because that is the part of the system a stranger can reach.
What we do not have Not in place
Stated because omitting it is how security pages mislead:
- No SOC 2, ISO 27001 or equivalent certification is held or claimed.
- No published penetration-test report.
- No formal bug-bounty programme, and no bounty payments.
- No contractual uptime guarantee.
If your procurement process requires any of those, that is a legitimate reason not to buy this yet, and it is better established now than during a security review.