Security

1. Authentication and sessions

• Email/password authentication with passwords stored using bcrypt hashing.
• Signed HTTP-only sessions; production cookies are configured secure and SameSite=Lax.
• Session validity is tied to current password/auth state and user updates so stale sessions can be invalidated.
• Super Admin authorization is separated from ordinary workspace access.

2. Tenant authorization

Customer data access is scoped through authenticated workspace/project membership. Resource identifiers alone are not authorization. Privileged administrative and entitlement operations remain separately authorised and auditable.

3. Database and data boundaries

The application accesses PostgreSQL server-side through Prisma. Committed migrations include row-level-security enablement/hardening, while application authorization remains required. Database credentials and direct migration credentials are not exposed to the browser.

4. External fetching and SSRF

Website crawling, implementation verification and AI Readiness paths use public-destination validation and protections against local/private network destinations and address-resolution edge cases. Redirects are bounded/revalidated and application credentials are not forwarded to arbitrary crawled hosts.

5. Billing integrity

Stripe webhook signatures are verified before authoritative billing state is processed. Server-side product, price, customer, workspace and subscription identity checks are used on billing-sensitive paths, and destructive subscription operations fail closed when identity is ambiguous.

6. Secrets and provider credentials

AI provider, Stripe, email, worker, cron and database credentials are server/worker-only deployment secrets. Production preflight requires strong application/worker/cron secret configuration and source-control secret scanning is part of the security workflow.

7. Sensitive routes and abuse controls

Sensitive and abuse-prone routes use shared database-backed rate limiting where implemented. Privacy request and deletion endpoints are rate limited; account-deletion requests additionally require authenticated password verification and explicit confirmation.

8. Vulnerability and dependency controls

The repository includes secret scanning and production dependency auditing. High/critical production dependency findings are intended to fail CI rather than being globally suppressed. Security-sensitive code changes remain subject to normal review and test controls.

9. Privacy and deletion controls

Privacy operations use explicit request states, identity verification, legal holds, deletion jobs, downstream processor review and minimal deletion receipts. Retention cleanup runs through an authenticated scheduled endpoint. Workspace ownership safeguards prevent a departing user from accidentally deleting a shared customer's data.

10. Incident handling

Operational guidance covers credential rotation, deployment secret replacement, source/history review, log/admin-event investigation and pausing destructive operations where tenant or billing identity is uncertain. Personal-data incidents are handled under the Privacy Policy and applicable notification requirements.

11. Certifications and testing

This page does not claim SOC 2, ISO 27001, a particular penetration-test cadence, a 24×7 SOC or another certification/control that has not been independently verified for MonitorMyGEO. Provider infrastructure certifications do not automatically become MonitorMyGEO certifications.

12. Reporting security concerns

Security concerns may be reported to support@monitormygeo.com. Do not include live credentials or exploit unrelated third-party systems when reporting an issue.