Bug Bounty Program

1. Expectation alignment

We are committed to building and serving a secure and stable product, and welcome security researchers from the community to participate in our bug bounty 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 bug 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

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, and we require a proof of attack written in detail as specified below.

3.2 Payment

We offer payment through PayPal and Wire transfers.If either of these are not an option for you, please reach out to us beforehand.

3.3 Timeframes

We aim to immediately review your report for severity upon submission, and to respond within 5 business days depending on the complexity of the report and the severity of the vulnerabilities found.

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.

4. Eligibility to Participate

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.

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.

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

Evidence and explanation of all steps required to reproduce the submission, which may include:

6. Good faith

To be eligible to participate in iPaper’s bug bounty program, we ask that all researchers act in good faith, which means:

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.

Don’t try to access other users’ accounts or data — respect their privacy.

Don’t use customer data or domains in your tests.

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.

Don’t upload rootkits, malware, or otherwise go beyond what is necessary to prove a vulnerability exists.

Don’t leave systems in a dirty or more vulnerable state.

Don’t take any action that could impact the performance or availability of iPaper’s admin, viewer or other services either internal or external.

Don’t make copies of iPaper’s private production data as “proof”. The report should suffice as proof of impact.

Be respectful of our team.

Failure to follow these rules will result in your reports being ineligible for bounty rewards.

7. Out of scope

Attacks requiring physical access to a user's device.

Any physical attacks against iPaper property or data centers.

Best practices violations (password complexity, expiration, re-use, etc.).

Tabnabbing / window.origin not being cleared on new tabs or windows.

Load testing / DDoS attacks (do not attempt or execute DDoS attacks - see this).

Homograph links.

Email DKIM.

Uploading and distributing files using our platform.

Accessing uploaded files that are not protected.

Attacks on our website hosting platform.

Attacks on our hosting providers.

Man-in-the-Middle attacks.

Spam attacks, social engineering directed at iPaper employees or customers.

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.

Vulnerabilities on third-party libraries without showing specific impact to the target application.

Any XSS that requires Flash. Flash is disabled by default in most modern browsers, thus greatly reducing the attack surface and associated risk.

Vulnerabilities only affecting users of outdated, unpatched, or unsupported browsers and platforms, including any version of Internet Explorer.

Most vulnerabilities within our staging environments.

Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls.

Modifying shop data-requests to change prices or other fields.

Trial account email signup and validation flow

8. Safe harbor

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.

Happy</hacking>