We've been excited to receive a number of vulnerability reports from security researchers all over the world since launching our security disclosure page earlier this year, and we've learned a lot about this process since we've published it. Privy is a more secure platform today because of the many reports we received.
One thing that's become clear is that we need to help researchers understand what we consider to be valid reports. The first version of our security page made a reference to two classes of excluded issues: XSS/Self-XSS and campaign asset information disclosure. We wanted to nip those in the bud, since we have received a steady stream of reports since even before we had an official channel to report security issues. I'd like to briefly elaborate on why these two issue types are excluded:
Campaign asset information disclosure: We occasionally receive security reports that campaign metadata or assets can be read under various unintended conditions (for example, getting a coupon code by inspecting network requests, instead of actually signing up for an offer with an email address). A merchant's promotional campaigns are intended for public consumption, so we don't make any guarantees about their privacy. Thus, exposure of assets like photos, coupon codes, free downloads, etc are not eligible for a security bounty or acknowledgment on our credits page.
These long-standing policies have served us well by allowing us to focus our time and energy on security vulnerability reports that are likely to pose the biggest threats to our merchants and our platform. Today, we're updating the bounty exclusions with five new categories: theoretical attacks, brute force attacks, attacks requiring physical access, account email management, and clickjacking.
In short, we've found that reports that fall in these categories tend to offer low returns on our effort, and sometimes run counter to our business goals. For example, we've seen multiple times that closing the reported vulnerabilities required breaking third party integrations, or important scenarios for many of our customers. Many reports in these areas targeted a series of deliberate and well-considered design tradeoffs we made, not an oversight. In others, we considered the likelihood of the various attack scenarios, the severity of the issue, and the potential breadth of the impact, and concluded the risk was small enough to ignore (attacks that require gaining physical access to a victim's device fall under this category).
There are valid scenarios in which combining multiple vulnerabilities can lead to actionable issues. Our goal is to evaluate those reports on a case by case basis, but we will generally not act on a straightforward vulnerability that falls under one of the above listed categories. We hope that these updated guidelines save time -- for both our team and researchers. Happy hunting.