Security.

Reporting a vulnerability

Email security@openpush.ai. Tell us what you found, how to reproduce it, and how you would like to be credited. We aim to acknowledge within two business days and to keep you updated until it is closed.

We will not pursue legal action against anyone acting in good faith under this policy: testing only against your own account or data, not accessing or modifying anyone else's data, not degrading the service, and giving us a reasonable window to fix the issue before publishing. We do not currently run a paid bug bounty. We do say thank you publicly if you want us to.

The same address is published at /.well-known/security.txt, and the full safe-harbour terms are on the vulnerability disclosure page.

What is in place

• Everything is over TLS. The site is served over HTTPS end to end, with HSTS, and sends no mixed content.
• The waitlist database denies by default. Row-level security is on with no policies, so the public API key can read nothing at all. The site writes through a server-side key that never reaches the browser.
• The waitlist stores no raw IP addresses. Abuse detection on this site uses a salted one-way hash instead. (The product itself is different — see “What you can switch off” below.)
• The public signup endpoint is defended. Per-IP rate limiting, a honeypot field, input validation on every field, and a database-level uniqueness constraint as the backstop.
• Security headers are set on every response: nosniff, a strict referrer policy, frame protection, and a restrictive permissions policy.
• No third-party scripts. There is no analytics, advertising or session-recording code on this site, so there is no supply chain to compromise through it.
• Secrets live in the deployment environment, never in the repository, and the repository is private until launch.

What is not in place yet

We do not hold SOC 2 or ISO 27001 certification, we have not commissioned a penetration test or an external security assessment, and we cannot sign a BAA. There is no formal bug bounty programme either. If your procurement process requires any of those, talk to us early rather than late — we will answer your security questionnaire directly and tell you honestly where we are.

What we do have: per-app credentials encrypted with AES-256-GCM and bound to their own row, TLS everywhere, role-based access with an exhaustive route-permission test, and a change-control record in the form of an 828-check suite that runs on every push.

And two architectural facts you can verify from outside without taking our word for anything: your notifications leave on your own APNs and FCM credentials, and there is no delivery network of ours in between to intercept them.

How the product handles your users' data

Push tokens and subscriber attributes are processed on your instructions and under the Data Processing Addendum. Delivery necessarily involves handing the token and payload to Apple's APNs or Google's FCM — every push platform does this, and both are named on the subprocessors page.

What you can switch off

Advertising identifiers, precise location and email addresses are off by default, per app, and stay off until you switch them on. Turning one off erases what was collected under it. We store IP addresses by default; OP_IP_STORAGE controls whether they are stored in full, truncated, or not at all.

The Privacy Policy covers what each of those is used for and how long it is kept.

Incidents

If a breach affects customer data, we notify affected customers without undue delay with enough detail to meet their own obligations, and we publish a write-up once the immediate risk has passed.