Security & Responsible Disclosure

We take the security of RnkRocket and our customers' data seriously. If you believe you have found a security vulnerability in one of our systems, we welcome your report and will work with you to understand and resolve it. This page explains how to report an issue, what is in scope, and the rules that govern good-faith security research on our services.

1. How to report

Please send vulnerability reports by email to security@rnkrocket.com. To help us triage quickly, include where you can:

• • A clear description of the issue and its potential impact
• • The affected URL, endpoint or component
• • Step-by-step instructions or a minimal proof of concept to reproduce it
• • Any relevant request/response samples, logs or screenshots

Please do not include real customer data in your report. Use your own test account where possible, and stop as soon as you have confirmed a vulnerability exists.

2. Our commitment (safe harbour)

If you make a good-faith effort to comply with this policy during your research, we will:

• • Consider your research authorised and will not pursue or support legal action against you for it
• • Acknowledge your report and work with you to understand and validate the issue
• • Keep you informed of our progress towards a fix
• • Not share your identity publicly without your permission

This safe harbour applies only to activity that stays within the scope and rules below. It does not authorise actions that break the law or that harm us, our customers, or third parties.

3. Scope

The following websites are in scope for good-faith testing:

• • rnkrocket.com and www.rnkrocket.com (marketing site)
• • app.rnkrocket.com (the application dashboard)

Reports about the behaviour of our APIs are welcome. However, active, direct testing of API endpoints, raw service endpoints, or worker and microservice hostnames (including any *.run.app URLs) requires our prior written permission — please email us first.

The following are out of scope:

• • Third-party services we rely on (for example Stripe, Supabase, Vercel, Google, Microsoft) — report those to the respective vendor
• • Our internal, staff-only and administrative systems, unless you have prior written permission from us
• • Findings that only affect an account you control, or that require access to another person's account, device or email
• • Social engineering of our staff, customers or vendors, and any physical security testing

4. Rules for research

To keep testing safe for everyone, please:

• • Only test using accounts, domains and data that belong to you
• • Stop and report as soon as you have minimally confirmed an issue — do not explore further to prove impact
• • Give us a reasonable opportunity to fix an issue before sharing it with anyone else — public disclosure must be coordinated with us and agreed in writing
• • Comply with all applicable laws

The following are prohibited:

• • Accessing, modifying, downloading or deleting another customer's project or data
• • Automated scanning or bulk testing without our prior written approval
• • Denial-of-service, load, stress, queue-exhaustion, quota-exhaustion or any other resource-exhaustion testing
• • Automated account creation or account farming
• • Credential stuffing, password spraying or brute-force attacks
• • Rate-limit bypass testing that creates meaningful traffic or cost
• • Attempts to reach localhost, private IP ranges, link-local addresses, cloud metadata endpoints or our internal infrastructure
• • Testing third-party infrastructure we rely on (for example Stripe, Supabase, Vercel, Google or Microsoft)
• • Spam, bulk form submissions, or deliberately triggering automated emails
• • Social engineering, phishing, or uploading malware
• • Maintaining access, installing backdoors, or any persistence after you have confirmed an issue
• • Destructive testing of any kind

5. Rewards

RnkRocket does not operate a paid bug-bounty programme, and we do not offer monetary rewards for reports. For valid, previously unknown vulnerabilities reported in good faith through the channel above, we are happy to offer our thanks and, with your permission, public acknowledgement once the issue is resolved. We do not respond to unsolicited demands for payment in exchange for the details of a vulnerability.

6. Findings we generally do not act on

The following are usually considered informational on their own. If you believe one of them is genuinely exploitable, a plausible, reproducible description of the impact is all we need — you never need to carry out prohibited activity (such as brute force, resource exhaustion, or touching another customer's account) to demonstrate it:

• • Missing security headers or cookie flags with no plausible impact
• • SPF, DKIM or DMARC configuration suggestions
• • Reports generated solely by automated tools with no analysis of real impact
• • Clickjacking on pages with no sensitive action, self-XSS, or best-practice suggestions without a plausible exploit path
• • Rate-limiting or brute-force concerns with no plausible account or data impact