CamsClaw

What CamsClaw does

CamsClaw is a public, passive vulnerability scanner. It probes a website's publicly visible surface — TLS configuration, HTTP security headers, DNS hygiene, CDN/WAF presence, exposed information, accessible login forms, API surface, and supply-chain integrity — and reports findings mapped to OWASP Top 10, PCI DSS 4.0, ISO 27001:2022, NIST 800-53, GDPR, India's DPDPA 2023, and the RBI Cyber Security Framework.

Every scan returns a 0-100 score and a letter grade (A+ to F), a list of findings with severities, and a permanent shareable report URL.

The three access layers

Not every test is safe to run on a stranger's website. So CamsClaw separates what it does into three layers, and you only unlock the deeper ones by proving you own the target.

1. Layer 1 — Public passive scan. Anyone can scan any public website, no sign-in required. This layer only reads: it inspects TLS, HTTP headers, DNS, and other publicly visible signals. It never sends an attack payload. This is the scan you get from the homepage.
2. Layer 2 — Verified-owner deep scan. Once you prove you control a domain, CamsClaw will look harder at your site than it would at a stranger's — still read-only, but more thorough.
3. Layer 3 — Consented active testing. For domains you own and have explicitly consented to test, CamsClaw will actually try a small, carefully bounded set of real attacks (see below) and hand you an evidence report of exactly what it sent and what came back.

Proving you own a domain

Layers 2 and 3 are gated behind ownership verification. Sign in, go to Verify a domain, enter your domain, and pick any one of three methods:

• DNS TXT record — add a TXT record at _camsclaw-verify.<yourdomain> with the value we give you, then click Check. Best for people who manage their own DNS.
• HTTP file — upload a small text file we provide to https://<yourdomain>/.well-known/camsclaw-verify.txt, then click Check. Best if you can publish a file but not edit DNS.
• Admin email — we email a one-time code to a standard administrative mailbox at your domain (admin@, postmaster@, security@, etc., per RFC 2142); paste the code back to confirm.

Verification is per-domain and is the only way to unlock active testing — there is no way to run an active scan against a domain you have not verified.

Layer 3: what an active scan actually does

When you launch an active scan on a verified domain, we first show you a consent screen that spells out, in plain language, exactly what will and will not happen. Nothing runs until you tick the box and confirm. We record that consent — who agreed, from which IP, at what time, and against which version of the terms — and that record is printed on your report.

What we send today (a deliberately small, low-risk set):

• Reflected-XSS canary — we submit a harmless unique marker in page parameters and check whether it comes back unescaped in the HTML. The marker does nothing on its own; it just proves whether an attacker's script could have been reflected.
• Error-based SQL injection — we send a single quote character in parameters and watch only for database error messages. We compare against a clean control request first, so a page that always errors doesn't trigger a false alarm. No UNION, no tautologies (OR 1=1), no time-delay or stacked queries — nothing that could read or change your data.
• Sensitive-file disclosure — we request a fixed list of files that should never be public (.env, .git/config, wp-config.php.bak, exposed /server-status, and similar) and flag any that return real, matching content.

What an active scan will never do: no denial-of-service or load testing, no password brute-forcing, no SSRF, no writing/modifying/deleting data, and nothing at all against a domain you haven't verified and consented for. Destructive and high-risk classes are intentionally out of scope.

Every single request an active probe makes is logged — the exact URL, the payload, the response status, and the response size. You can download this complete audit trail as a PDF ("Download evidence" on the scan report) so you have a defensible, timestamped record of precisely what was tested. You can withdraw consent at any time from your dashboard.

What CamsClaw does not do

• No active testing on unverified targets. Public Layer-1 scans are limited to read-only HTTP GETs and DNS queries — no attack payloads of any kind. Active probes (the bounded set described above) run only against domains you have verified and explicitly consented to test.
• No denial-of-service or brute-force, ever. Even on a consented active scan we never flood a target, never test passwords, and never run anything designed to disrupt availability.
• No private networks. We refuse to scan RFC1918 addresses, link-local, loopback, CGNAT, or reserved TLDs (.local, .internal, .test, etc.). Targets resolving to private IPs are rejected at the API.
• No credentials, ever. We never submit login forms or guess passwords. Deeper Layer-2 and Layer-3 access requires explicit DNS, HTTP-file, or admin-email proof of ownership first.
• No professional pentest replacement. Findings are best-effort signals, not a SOC 2 audit. Use them to find low-hanging fruit, then engage a qualified firm for deeper assurance.

How we identify ourselves

Every outbound request from CamsClaw scanners carries this User-Agent:

CamsClaw/0.x (+https://camsclaw.ai/about; abuse@camsclaw.ai)

If your WAF or analyst sees this UA and you have questions, please contact us — the email above goes directly to a human. We also publish /.well-known/security.txt per RFC 9116.

What we store

• Each scan is persisted with a UUID, target hostname, score, grade, and the full findings list. Reports remain public unless removed on owner request.
• We log request method, path, response code, and source IP for operational purposes (rate limiting, abuse investigation). Logs are kept for 90 days.
• We do not run analytics, tracking pixels, third-party scripts, cookies, or any user-tracking infrastructure on the public site.

Rate limits

• 30 scans / hour / IP — handles individual exploration.
• 200 scans / day / IP — handles small-batch research.

If you need higher limits for legitimate research, email us — we're happy to allowlist verified academic, journalistic, or security-research use.

Opt-out / takedown

If you are the verified owner of a domain and want to remove its public scan history, email abuse@camsclaw.ai from a domain-attributable address (e.g. security@yourdomain.com) — we'll honor takedown requests within 48 hours and add the domain to a non-scan list. Verifying domain control via our POST /api/verify flow speeds this up considerably.

Disclaimer

CamsClaw is provided as-is, without warranty. Findings are generated by automated probing and may include false positives or miss true positives. The Cams project is not liable for actions taken based on a CamsClaw report. Always validate findings before public disclosure or remediation prioritization.

Source

The full source is at git.camsbiometrics.com:8443/cams/camsclaw — the scanner code, scoring logic, sector lists, everything. PRs welcome.

"Wrong location" on the homepage recon panel?

The geo_estimate field on the homepage terminal panel is derived from your public IP via a third-party geolocation database. IP-based geolocation is fundamentally imprecise — it tells you where the IP block is registered, not where the user physically is.

Common reasons it's "wrong":

• ISP backbone routing — your traffic exits through your ISP's nearest peering point, which may be in a different city than you. A Chennai user on Tata Play whose traffic routes through Bangalore-peering will geolocate to Bangalore.
• Stale database — IP allocations change as ISPs grow; databases can lag by months.
• Mobile carriers — often appear at the carrier HQ, not your tower.
• VPN / corporate proxy — geolocates to the exit IP, not your seat.
• IPv6 vs IPv4 — sometimes the v6 block is geolocated differently from the v4 block of the same household.

This is why we label the field geo_estimate and add the "best-effort, IP-derived" comment — it's not a bug in CamsClaw, it's the nature of IP geolocation. We don't use this field for anything beyond display + the "submitted-from" context shown to our sales team on demo-request submissions.

If precise location matters to you (it usually shouldn't on a security scanner), the timezone field is browser-resolved and is therefore as accurate as your OS clock.

Contact

• General / abuse: abuse@camsclaw.ai
• Security disclosures (about CamsClaw itself): see /.well-known/security.txt
• Project: Cams · Cams Biometrics, Chennai, Tamil Nadu — 600119, India