Security is core to keeping Snipp safe for everyone, and we rely on researchers to help us find and fix vulnerabilities quickly. If you've discovered a security issue, we want to know about it. We appreciate every responsible disclosure, happy hunting!
We will never pursue legal action against anyone who reports vulnerabilities in good faith and follows the guidelines on this page.
We aim to acknowledge every report within 48 hours and will keep you updated throughout the resolution process.
Depending on the severity and impact of your finding, you may be eligible for an exclusive profile badge and free months of our PLUS subscription.
Researchers who make meaningful contributions to Snipp's security can earn profile badges displayed publicly on their account.
Awarded for your first valid vulnerability report. Recognizes researchers who help make Snipp safer.
Awarded after 3-5 exceptional reports or a single critical finding. Reserved for active researchers who uncover the most impactful issues.
All testing must be performed on your own accounts. Never interact with or impact other users' data or accounts.
Only Snipp-operated services are in scope. Reports targeting third-party platforms, even those integrated via our API, will not be accepted.
Avoid any activity that could degrade our services or compromise data integrity. This includes brute forcing, DoS, spamming, and timing-based attacks.
Automated scanning tools are not allowed. All testing should be done manually.
We may temporarily exclude certain vulnerability classes from scope while we address them internally. Any changes will be reflected on this page.
Please keep all findings confidential until we've fully investigated and resolved the issue.
Responsible disclosure is the best way to help us fix issues quickly while minimizing risk. When you report directly to us, we can begin working on a fix immediately without exposing the vulnerability to bad actors.
Findings that are shared publicly before we've had a chance to address them, whether on social media, forums, or anywhere else, will not be eligible for badge recognition. We want to credit the people who give us the opportunity to fix things first.
If multiple people report the same issue, we'll evaluate submissions based on:
Clarity of the technical explanation
How well the report conveys the real-world impact
Timestamp of submission
A report must demonstrate real-world impact. A CVSS score on its own, without a working proof of concept showing what an attacker actually gains, is treated as informational and is not eligible for a reward.
We genuinely appreciate every researcher who takes the time to help make Snipp safer.
Some data is public on purpose. Information that already appears on public pages is not confidential, and reading it, whether through the site, an API endpoint, or while logged out, is not a vulnerability. Before reporting a data exposure, check whether the same data is already shown publicly. The following are public by design:
Profile information shown on a user's public page: username, display name, avatar, banner, bio, linked socials, join date, and follower and following counts.
Profile badges and the status behind them, including staff, partner, bug hunter, translator, verified, and supporter. These are displayed publicly as badges.
Post information on a public or unlisted post: title, description, media, view count, and upload date.
Viewer-relative flags that only reflect your own session, such as whether a profile is your own, whether you follow a user, or whether a block exists between you and them. These describe your relationship to the data, not anyone else's private information.
Before submitting, think about whether the issue has a realistic attack scenario and a meaningful security impact. The following are generally excluded:
Disclosure of data that is already public by design (see the section above), including profile fields, badges, post metadata, and viewer-relative flags
Reports based on client-side validation alone. Security checks are enforced on the server, so a missing client-side check is not a vulnerability when the server rejects the same input
File type, MIME, or extension handling on uploads. Uploaded files are validated by their actual content on the server, and the stored type is never taken from the client
Disclosure of an origin IP address, infrastructure provider, or unproxied subdomain. Some services, such as upload endpoints, are intentionally served outside the CDN and are hardened at the origin
Stale or historical DNS records that no longer point to live infrastructure
Missing or misconfigured security headers, such as CSP, HSTS, or X-Frame-Options, without a demonstrated working exploit
Verbose error messages, stack traces, or software version disclosure without a demonstrated working exploit
Enumeration of valid resources by identifier, or 4xx and 5xx responses to invalid identifiers. Returning a not-found status to an invalid request is expected behavior
Account enumeration
Attacks requiring MITM or physical access to a user's device
Clickjacking
Content spoofing and text injection
CSRF vulnerabilities
Email SPF, DKIM, and DMARC records
Missing HttpOnly/Secure cookie flags
Open CORS headers
Rate limiting
Reports from scanners and automated tools
Self-exploitation (like token reuse and console scripting)
Social engineering or phishing attacks targeting users or staff
External services, partners, and integrations are outside the scope of this program. Only vulnerabilities in Snipp-owned features and APIs qualify. Reports must show a clear security impact to Snipp itself.
Any scenario where an attacker could obtain another user's API keys, session tokens, or credentials without relying on social engineering is considered in scope.
Reproducible website crashes caused by crafted input or normal user interaction are considered in scope, provided they do not depend on resource exhaustion, spam, or other denial-of-service techniques.
Reports that depend on exploiting a race condition need additional evidence to be accepted. Please include at least one of the following:
A reproducible script (Python or JavaScript preferred, though other languages are fine)
A thorough writeup covering the HTTP methods, endpoints, and exact request ordering needed to trigger the condition
Including a script makes it much easier for us to verify the issue and speeds up the review process.
Send us an email with a clear description of the issue, steps to reproduce, and any supporting evidence. We'll get back to you as soon as we can.