Security

• SOC 2: we do not hold a SOC 2 report yet. We hold no ISO 27001 certificate either.
• Penetration test: no third-party penetration test yet.
• SSO (SAML/OIDC): SSO is not available yet. You can sign in with email and password or with Google.
• Two-factor sign-in: not available yet.
• Subprocessors: listed on our subprocessors page.
• DPA: see Data processing for roles and how to request one.

SlapMyWeb runs on a single virtual private server (VPS) from Hostinger. The website, API, background worker, PostgreSQL database and Redis queue all run on that server. The database and Redis listen only on the server's local interface (127.0.0.1), not on the public internet.

Cloudflare sits in front of slapmyweb.com and api.slapmyweb.com for DNS, caching and TLS. We do not state the data-centre region here yet.

• Browsers reach us over HTTPS through Cloudflare. We send HSTS (one year, including subdomains, preload).
• Our server is set up to accept TLS from Cloudflare, using a self-signed certificate.

• Third-party credentials are encrypted with AES-256-GCM before they are stored: platform API keys, Google, Notion, HubSpot and Cloudflare tokens, Bing keys you paste, and signing secrets for agency webhooks (Dashboard → Webhooks).
• Passwords are hashed with bcrypt (cost 12). We cannot read your password.
• Public API keys are stored as hashes; the full key is shown once, when it is created.
• The database disk and the backup file are not separately encrypted by us. Any encryption of the underlying storage is up to the hosting provider and is not verified by us.

• Sessions use signed JSON Web Tokens with the algorithm pinned to HS256. Access tokens last 15 minutes; refresh tokens last 30 days.
• After 5 failed sign-in attempts an account is locked for 30 minutes.
• Features are gated by plan on the server, not only in the interface.
• Agency workspaces have three roles: owner, admin and member.
• Public API keys carry per-plan rate limits, stored in Redis. Sign-in, scanning and other public endpoints are rate limited too.
• Admin screens require an admin role on the account.

• Requests to the websites you audit go through a guard that blocks private, internal and cloud-metadata addresses.
• API and queue inputs are validated with Zod before they reach the database.
• The API sets security headers with Helmet; the website sends a Content-Security-Policy.

• The PostgreSQL database is dumped once a day at 03:23 server time (Asia/Karachi) by a scheduled job.
• Each dump is checked against a checksum. Only the newest verified dump is kept, and it is kept on the same server.
• We have no off-site backup copy yet. Data written since the last dump (up to 24 hours) could be lost if the server failed.

• Application logs redact values that look like passwords, tokens, API keys, authorization headers and cookies.
• An audit log table records report exports and admin changes to platform settings, with the user, time and IP address. Sign-ins are not written to it yet.
• The web server keeps access logs for our domains.

• Scan results are kept until you delete them. We do not delete scans automatically today.
• Search Console, GA4 and Bing data you connect: up to 400 days of daily history, then older rows are deleted.
• AI visibility results: kept for 400 days, then deleted.
• The database backup is replaced every day, so a deleted record leaves the backup within about a day.

• You can delete individual scans from your scan history; they are removed from the database.
• Deleting your account (Settings → Danger zone) signs you out everywhere at once and deletes your connected Google and Bing data and tokens straight away.
• Your account record is marked as deleted; your scans and other records are kept until you ask us to erase them by email at info@slapmyweb.com.

Every outside service that receives customer data is listed on the subprocessors page, with what it receives and when. For roles under data protection law and how to request a DPA, see Data processing. What we collect and why is in the privacy policy.

Report a suspected security incident affecting your account to security@slapmyweb.com. Security questionnaires and other questions: contact the team.

Found a vulnerability? Email security@slapmyweb.com. Our contact details are also in our security.txt. We will not pursue good-faith researchers who report to us privately and give us time to fix the issue.