Security and Vulnerability Disclosure
Effective Date: 31 October 2026
We take the security of RapidNative and our users' projects seriously. If you believe you have found a security vulnerability in RapidNative, we want to hear about it. This page explains how to report it, what you can expect from us, and the rules we ask you to follow while you research.
1. HOW TO REPORT
Email support@rapidnative.com with "Security" in the subject line. Please include:
- The affected URL or API endpoint
- Step-by-step instructions to reproduce the issue
- What an attacker could do with it (the impact)
- A proof of concept, such as a request, script or short video
A report with these details lets us confirm and fix the issue quickly. A report that only says a vulnerability exists, without describing it, cannot be acted on.
2. WHAT WE COMMIT TO
- Acknowledge your report within 3 business days.
- Keep you updated while we investigate and fix it.
- Fix confirmed issues, prioritised by severity.
- Credit you on this page once the issue is fixed, if you would like to be named.
3. NO PAID BUG BOUNTY
We do not run a paid bug bounty program and cannot promise a monetary reward for any report. We review every report we receive, fix what is real, and publicly credit researchers who want it.
4. SCOPE
In scope:
- rapidnative.com and www.rapidnative.com, including the editor and dashboard
- The RapidNative API
Out of scope:
- Apps built by our users, and the preview hosts that serve them (*.rapidnative.app). Report issues in a user's app to that app's owner. Issues in the preview platform itself are in scope.
- Third-party services we use, such as Supabase, Stripe and Vercel. Report those to the vendor.
- LetsDeployIt (letsdeploy.it), which publishes its own policy.
5. NOT ELIGIBLE
The following are not treated as vulnerabilities unless you can show a concrete, exploitable impact:
- Missing or misconfigured HTTP security headers
- SPF, DKIM or DMARC configuration
- Clickjacking on pages with no sensitive actions
- Self-XSS, or CSRF on logout and other non-sensitive actions
- Software version or banner disclosure
- Rate limiting on endpoints that are not authentication or payment related
- Output from automated scanners without a working proof of concept
- Issues that require physical access to, or a compromised, victim device
6. SAFE HARBOR
We will not pursue legal action against research carried out in good faith under this policy. In return, we ask that you:
- Only access, modify or keep other users' data to the extent needed to prove the issue, and stop as soon as you have
- Test against your own account and projects wherever possible
- Do not run denial-of-service attacks or degrade the service for other users
- Do not use social engineering, phishing or spam against our team or users
- Give us reasonable time to fix the issue before disclosing it publicly. We ask for 90 days from your report, and will coordinate a disclosure date with you.
7. ACKNOWLEDGMENTS
We thank the researchers who have responsibly reported issues to us. Names are added here, with permission, once a fix has shipped.
8. MACHINE-READABLE CONTACT
Our contact details are also published at /.well-known/security.txt, following RFC 9116.