Security practices and legal pages

This article describes the security controls that NearbySpy applies across the platform and points you to the legal pages that govern your use of the service. It is meant for Investigators, Clients, and prospective customers who want to understand how their account, Cases, and files are protected.

Authentication and session handling

NearbySpy uses Supabase Auth for all sign-in and sign-up flows. Sessions are stored in HTTP-only cookies that the browser cannot read from JavaScript, which mitigates a large class of cross-site scripting risks. We do not store session tokens in localStorage. Every sensitive route verifies the active session on the server before reading or writing data.

Sign-in options

• Email and password. Passwords must meet length and complexity rules — see Password rules and keeping your account secure.
• Google OAuth. Federated sign-in delegated to Google. Detailed in Signing in with Google.
• Phone OTP. Used for phone verification on certain flows — see Phone verification and OTP troubleshooting.

Authorization and data scoping

Every database query for Case data goes through Postgres row-level security. The check considers the platform role, account level, Case role, and Operation visibility before returning rows. Application code cannot bypass these policies. For the full picture see Privacy basics for Cases and Evidence.

API hardening

API routes follow a strict pipeline: authenticate, check role-based permissions, validate the request payload with Zod, then execute. Database access uses parameterized queries — never string-concatenated SQL. File uploads are validated by their actual content type on the server, not by a client-supplied MIME header. Failed authorization returns the correct HTTP status — 401 for unauthenticated, 403 for unauthorized, 404 when the resource exists but the requester is not entitled to know about it.

Evidence integrity

Files uploaded as Evidence are hashed client-side with SHA-256 before transmission, then re-verified after the upload completes. The hash, file size, uploader, and timestamps are all stored on the Evidence record and shown in the audit history. Read How Evidence upload and integrity (hashing) work for the chain-of-custody rationale.

Audit logging

Audit tables are append-only. Both successful and failed access attempts are recorded for Cases, Operations, Evidence, permissions, member changes, and Client view events. We do not delete audit history when a Case is archived.

Transport and infrastructure

All public endpoints are served over HTTPS. The application runs on Vercel with Supabase as the system of record. Storage objects are not directly exposed by predictable URLs to unauthorized roles.

Legal pages

Public legal documents are linked from the footer of every marketing and dashboard page. These include the Terms of Service, the Privacy Policy, and any data processing addenda you need for client review. If you cannot find a specific document, contact us via the methods in Contact form reasons and what to include.

Reporting a vulnerability

If you believe you have found a security issue, please contact support and mark the ticket as a security report. We do not publicly disclose unverified claims and we appreciate responsible reporting from Investigators and researchers.