Security Overview

Every control below was confirmed against the running source before it was published here. Items we could not confirm are listed in "What we do not claim" at the bottom rather than quietly omitted.

Transport and browser hardening

• HTTPS only. HTTP is redirected, and outside development the response carries an HSTS header.
• Content Security Policy with a per-request nonce. A fresh 128-bit nonce is generated for every response and is the only way an inline script executes. The policy also sets frame-ancestors 'none', object-src 'none', base-uri 'self' and form-action 'self'.
• X-Frame-Options: DENY — the site cannot be framed.
• X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a Permissions-Policy that disables geolocation, microphone, camera, payment and USB.

Accounts and sessions

• BCrypt password hashing on registration, login and reset. A dummy verification runs when an account does not exist so login timing does not disclose whether an email is registered.
• Cookie authentication with HttpOnly, Secure always on, and SameSite=Lax.
• Session revocation. A security stamp is revalidated against the database on each request, so a password reset invalidates every existing session immediately.
• Minimum password length of 8 characters, enforced server-side.
• Email verification by one-time code, with an attempt cap that invalidates the outstanding code.
• Data-protection keys are persisted to a configured directory so sessions survive a restart without being re-keyed in memory.

Abuse resistance

• reCAPTCHA v3 with a server-side score check on registration, password reset, the contact form, the listing-request form, company setup and scrape review; on login it is required after repeated failures.
• Rate limiting on seven separate policies — contact, authentication, scraping, authenticated API, directory search, directory metadata and webhooks — partitioned by user id where available and otherwise by client IP, returning HTTP 429.
• Antiforgery tokens on every state-changing form post.
• Same-origin enforcement on the few JSON endpoints that opt out of antiforgery: Sec-Fetch-Site, then Origin, then Referer are checked and the request is rejected with 403 if none of them proves a same-origin call. It fails closed.
• Upload validation. Claim and verification documents are checked for both extension and file signature, capped at 5 MB each, and stored outside the web root behind an authenticated, ownership-checked download route that sets X-Robots-Tag: noindex.

Outbound requests

• SSRF-safe scraping. Before any company website is fetched, the URL must use http or https, must not resolve to a loopback, private (10/8, 172.16/12, 192.168/16), link-local (169.254/16, including the cloud metadata endpoint), CGNAT (100.64/10), IPv4-mapped IPv6 or IPv6 unique-local address, and must not use a localhost, .local or .internal hostname. Requests are additionally capped by page count, byte size, redirect count and timeout, and robots.txt is respected.
• HMAC-SHA512 webhook verification. NOWPayments IPN callbacks are verified against a canonical, key-sorted serialisation of the raw body using a constant-time comparison, and are rejected outright when no shared secret is configured.
• Trusted proxies only. Forwarded client-IP and scheme headers are accepted from loopback (and explicitly configured proxies) only, so an external client cannot spoof its address into the rate limiter.

Data handling

• Password-reset and verification tokens are stored as SHA-256 hashes; the raw token exists only in the email.
• Scrape request metadata stores a truncated SHA-256 hash of the client IP rather than the address itself.
• Scheduled deletion of operational data — see Data Retention.
• Administrative plan and role changes are written to an audit log.

What we do not claim

These are real gaps, published so that nobody has to discover them in a questionnaire:

• No published backup schedule or backup-encryption guarantee. No backup job, retention schedule or encryption-at-rest statement for backups exists in the deployed code, so we make no commitment about backup frequency, encryption or restore time.
• No redirect re-validation in this application. The initial scrape URL is SSRF-checked here, but per-hop redirect validation happens in the search backend and is not asserted on this page.
• No account lockout. Repeated failed logins escalate to a CAPTCHA and are rate limited; the account itself is never locked.
• No formal certification. See Certification status.
• No published penetration-test report and no bug-bounty programme. Vulnerability reports are still welcome at support@shelftap.com.
• The CSP allows inline styles and a small allowlist of script hosts (Google Tag Manager, Google reCAPTCHA, jsDelivr), so it is not a strict-dynamic policy.