What actually protects your data
ExploitSense is self-hosted — you run it on your own infrastructure, and scan data never leaves it. This page describes the specific controls built into the software itself, each pointing at the real source file that implements it.
Credentials encrypted at rest
SSH/network credentials you store for internal scanning are encrypted with AES-256-GCM before they touch the database, with an explicitly pinned authentication-tag length rather than a caller-supplied one.
src/lib/crypto.ts
Argon2id passwords, TOTP and passkey 2FA
New account passwords are hashed with Argon2id (memory-hard, GPU/ASIC-resistant); older bcrypt hashes are transparently upgraded on next login. Optional TOTP authenticator apps and WebAuthn/passkey sign-in are both supported.
src/lib/auth.ts
Revocable sessions, not just expiring ones
Signed session tokens carry a per-account token version and a per-session ID. Changing your password, or an admin revoking a specific session, invalidates it immediately — it doesn't wait for the token to expire on its own.
src/lib/session-validity.ts
Account isolation, verified live
Every record — scans, findings, credentials, assets — is scoped to the owning account at the database query level. This isn't just a code-review claim: an automated test suite creates two real accounts against a real database and confirms neither can read the other's data before every release.
src/app/api/tenant-isolation.test.ts
SSRF-hardened scanning
Scan targets and webhook URLs are checked against private-IP and cloud-metadata ranges, including the IPv4-mapped IPv6 form (::ffff:169.254.169.254) that a naive check misses. Webhook targets are re-checked immediately before delivery, not just when you save the URL, since DNS can change underneath you.
src/lib/validation.ts
Tamper-evident audit log
Every audit entry is chained to the previous one by hash, the same structure a blockchain or git commit history uses. Editing or deleting a past entry breaks the chain in a way that's cryptographically detectable, not just logged.
src/modules/audit/verify-chain.ts
How this is tested, not just claimed
Dependencies are checked with npm auditand patched when a fix exists without breaking compatibility. Static analysis (Semgrep) runs against the codebase before release. The full test suite runs against real infrastructure where it matters — a real Postgres database for the account-isolation tests, real HTTP servers for scan-output regression tests — rather than mocking away the parts most likely to hide a real bug. None of this is a substitute for an independent third-party audit, which hasn't been performed on this codebase — it's what internal engineering practice actually looks like here, described honestly rather than oversold.