Responsible disclosure

How to report

Email support@receivevault.com with "security" in the subject line. Include enough detail to reproduce the issue: the URL or endpoint, the steps, and what you expected to happen instead. A short proof of concept is worth more than a scanner report.

If the issue is serious enough that details should not sit in a mailbox, say so in the first email and we will arrange another channel before you send anything further.

What we will do

• Acknowledge within 3 business days. We are a small team, so this is a person reading your email, not a ticket robot.
• Give you an assessment within 10 business days - whether we agree it is a vulnerability, how serious we think it is, and what we intend to do.
• Fix what we agree is real, and tell you when it has shipped so you can verify the fix yourself.
• Credit you by name or handle if you want it, and stay quiet about you if you do not.
• Not pursue you for good-faith research that follows the rules below. We will not send lawyers after somebody who helped us.

We do not run a paid bug bounty. We are honest about that up front rather than implying a reward that never arrives.

Rules for testing

The line is other people's documents. Almost everything else is negotiable; that is not.

• Use your own accounts and your own data. Sign up for a free trial and test against that. Do not access, download, modify or delete any account, file, or upload link that is not yours.
• Stop at proof. Once you can show an issue exists, stop. Do not pivot deeper, and do not extract more data than the minimum needed to demonstrate it.
• No denial of service, no load or stress testing, no spam or mass automated requests against the live service.
• No social engineering of our staff, our customers, their contacts, or our vendors, and no physical intrusion.
• Do not publish before we have had a reasonable chance to fix it. 90 days is the norm we work to, and we will usually be much faster; if we go quiet on you, tell us you intend to publish and give us a date.
• Tell us if you saw something you should not have. Accidentally reaching another account's data is exactly the kind of finding we need reported. Say what you saw, delete your copy, and we will treat the disclosure as good faith.

In scope

• The application and its API, including the contact-facing upload and download pages.
• Anything that lets one account reach another account's data, or lets a magic link reach a file it was not issued for.
• Authentication, multi-factor authentication, session handling, and the sudo re-verification flow.
• Anything that causes a file to be stored, served or deleted contrary to what the interface says will happen.

Out of scope

Reports of the following are usually closed without action, unless you can chain them into something with real impact - in which case, show us the chain and we will look properly.

• Missing security headers, TLS configuration preferences, or cookie flags with no demonstrated impact.
• Automated scanner output with no proof of exploitability, and best-practice findings restated as vulnerabilities.
• Rate limiting on unauthenticated endpoints, absent a demonstrated account takeover or data exposure.
• Self-XSS, clickjacking on pages with no state-changing action, and issues that require a fully compromised device or browser.
• Email spoofing findings already addressed by our published SPF and DMARC records.
• Vulnerabilities in third-party services - report those to the vendor directly. Our sub-processors are listed on our sub-processors page.

Machine-readable contact

This policy is referenced from /.well-known/security.txt, per RFC 9116. Its Expires field is set 180 days ahead and refreshes on each fetch, so the contact address it names is always one we are actually watching.