We are committed to building and serving a secure and stable product, and welcome security researchers from the community to participate in our Security Disclosure Program. On this page you will find all the information needed to disclose with us, and what you can expect from us as well as our expectations of you and your report.
2. How to disclose
Please submit your full report to: disclosure@ipaper.io with as much information as possible based on the guidelines specified below.
3. Rewards
We offer rewards depending on the severity of the vulnerability found as well as the completeness of the report. The severity is determined solely at the discretion of iPaper after we have reviewed your report.
3.1 Severities
Best practice
Low
Medium
High
Critical
$0
Up to $50
Up to $250
Up to $500
Up to $1000
3.1.1 Best practice
We generally do not offer rewards for things that are “best practice” only. This also means that we will not issue rewards for using automated vulnerability scanners to detect common things or things like missing headers, and we require a proof of attack written in detail as specified below.
3.1.2 Low
Issues that are of low severity could be issues like race conditions, missing rate limits or other bugs that have little or no security implications.
3.1.3 Medium
Medium severity things could be issues like accessing own account features you do not have access to, some DNS misconfigurations or other issues that could have security risks.
3.1.4 High
High severity things could be issues like accessing protected files, accessing private assets on other accounts, injecting malicious content and other more severe security issues.
3.1.5 Critical
Critical severity things could be issues like bypassing authentication or 2FA, escalating user privileges, accessing accounts, servers, databases, or other infrastructure and sensitive security holes.
3.2 Payment
We only offer payment through PayPal, please make sure this is an option for you before proceeding, or reach out to us beforehand.
3.3 Timeframes
We aim to quickly review your report for severity upon submission, but depending on the volume of reports or holidays, we cannot offer you a timeframe to receive a response.
Once a report has been reviewed we will discuss the report with you and dispatch payment shortly thereafter if it qualifies for a payment.
Depending on the severity or complexity of the issue we might not be able to offer a timeframe for a fix to be completed.
3.4 Duplicate issues
We track all issues disclosed with us, and will not be able to reward for duplicate issues that are submitted to us.
3.5 Eligible domains
Domains that are pointing to inactive accounts/sites are also in scope as we would like to be notified so we can remove them.
That you are of legal age in your country - or have written parental consent.
That you are not violating any laws.
That you are not currently or previously employed with iPaper.
That you will not disclose any information except with the iPaper team.
That you do not live in or work for a company that is currently sanctioned by the EU or the UN - we will not be able to provide payment or interact further if we discover that you are from a sanctioned entity.
5. Report Quality
Reports are expected to be thorough and contain enough information that the iPaper team can easily duplicate any findings. If specially crafted files are used, they should be submitted as attachments. Screenshots and videos are encouraged but should be accompanied by descriptions and explanations. Submissions should not consist solely of a video or screenshots.
Reports are welcome for issues that cannot be proven but still suggest a serious impact. We trust reporters to make that determination and will assist in clarifying impact and adjusting the severity as needed. It is better to report a vulnerability early while we help determine the impact rather than waiting days or weeks to create proof.
5.1 Expectations to the report
Full description of the vulnerability being reported, including the exploitability and impact to our systems
Reports based solely on copy/paste from automated testing tools will not be accepted.
Reports that are clearly copy/paste from other sources without testing our platform will not be accepted.
Evidence and explanation of all steps required to reproduce the submission, which may include:
Screenshots / Videos (.mp4 only)
Exploit code
Web/API requests and responses
Email address or user ID of any test accounts
IP address/Account(s)/Email-addresses used during testing
Failure to include any of the above items may delay or jeopardize the Bounty Payment
6. Good faith
To be eligible to participate in iPaper’s Security Disclosure Program, we ask that all researchers act in good faith, which means:
6.1
Don’t publicly disclose a vulnerability without iPaper’s explicit consent and don’t discuss vulnerability details with anyone other than iPaper staff before we can patch the vulnerability.
6.2
Don’t try to access other users’ accounts or data — respect their privacy.
6.3
Don’t use customer data or domains in your tests.
6.4
Don’t leverage internal access to continue testing. For example, if you have gained remote command execution on a server do not use that access to start scanning or exploring our internal systems. We will assess what, if anything, you could pivot to from your initial report and assess the impact based on that, even if you don’t identify the possibility yourself.
6.5
Don’t upload rootkits, malware, or otherwise go beyond what is necessary to prove a vulnerability exists.
6.6
Don’t leave systems in a dirty or more vulnerable state.
6.7
Don’t take any action that could impact the performance or availability of iPaper’s admin, viewer or other services either internal or external.
6.8
Don’t make copies of iPaper’s private production data as “proof”. The report should suffice as proof of impact.
6.9
Be respectful of our team.
Failure to follow these rules will result in your reports being ineligible for bounty rewards.
7. Out of scope
7.1
Attacks requiring physical access to a user's device.
7.2
Any physical attacks against iPaper property or data centers.
7.3
Best practices violations (password complexity, expiration, re-use, etc.).
7.4
Tabnabbing / window.origin not being cleared on new tabs or windows.
7.5
Load testing / DDoS attacks (do not attempt or execute DDoS attacks - see this).
7.6
Homograph links.
7.7
Email DMARC and DKIM.
7.8
Uploading and distributing files using our platform.
7.9
Files stored on our CDN endpoints (*.cdn.ipaper.io and others)
7.10
Accessing uploaded files that are not protected.
7.11
Attacks on our website hosting platform.
7.12
Attacks on our hosting providers.
7.13
Man-in-the-Middle attacks.
7.14
Spam attacks, social engineering directed at iPaper employees or customers.
7.15
Any other submission determined to be very low risk, based on unlikely or theoretical attack vectors, requiring significant user interaction, or resulting in minimal impact.
7.16
Vulnerabilities on third-party libraries without showing specific impact to the target application.
7.17
Any XSS that requires Flash. Flash is disabled by default in most modern browsers, thus greatly reducing the attack surface and associated risk.
7.18
Vulnerabilities only affecting users of outdated, unpatched, or unsupported browsers and platforms, including any version of Internet Explorer.
7.19
Most vulnerabilities within our staging environments.
7.20
Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls.
7.21
Modifying shop data-requests to change prices or other fields.
Any activities conducted in a manner consistent with this policy will be considered authorized conduct, and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
9. Terms
We reserve the right to modify or terminate this program at any time.