Bug Bounty Program

1. Introduction

dosya.dev stores other people's files. That makes the security of this service the most important thing about it. If you find a way to break it, we want to hear from you before anyone else does.

We are a small team. Every report is read by a human, not a queue bot. In exchange for that, we ask for clear reproduction steps and a little patience.

2. Rewards

We pay for valid, previously unknown vulnerabilities. Reward size is scaled to the severity and real-world impact of the issue, and is set at our discretion once we have reproduced and triaged the report. We do not publish a fixed price list, because the value of a finding depends on what it actually lets an attacker do.

Every valid report also earns:

• A credit in our Hall of Fame, if you want one. Staying anonymous is fine too.
• Storage credit on your dosya.dev account.

Payment is arranged with you after the report is confirmed. We can pay by PayPal, Wise, or a gift card of your choosing, whichever works best where you are.

What raises a reward: a working proof of concept, a clear impact statement, and a report we can act on without a round of clarifying questions. What lowers it: a scanner dump, a duplicate of something already reported, or an issue that needs an unrealistic precondition.

3. Severity Guide

We triage against the practical question "what can an attacker actually do with this?" Roughly:

Critical

• Reading, modifying or deleting another user's files.
• Remote code execution on our infrastructure.
• Full account takeover without user interaction.
• Dumping the database or bulk-extracting user records.

High

• Authentication or two-factor bypass.
• Cross-workspace data access: reaching a workspace you are not a member of.
• Escaping the scope of an API key, share link, or presigned URL.
• Path traversal in the WebDAV, S3, or SFTP gateways.
• Privilege escalation to workspace owner or staff.

Medium

• Stored cross-site scripting.
• Insecure direct object reference exposing non-sensitive records.
• Cross-site request forgery on a state-changing action.
• Server-side request forgery with limited reach.
• Bypassing a storage quota or billing limit.

Low

• Reflected cross-site scripting needing heavy user interaction.
• Missing or bypassable rate limits with no further impact.
• Minor information disclosure, such as internal version numbers or stack traces.
• Open redirect.

4. In Scope

Anything dosya.dev owns and operates:

• dosya.dev - this marketing site.
• app.dosya.dev - the web dashboard.
• api.dosya.dev - the REST API, including the WebDAV and S3-compatible gateways.
• sftp.dosya.dev - the SFTP endpoint.
• portal.dosya.dev - the staff admin portal.
• status.dosya.dev - the status page.
• Desktop app - Windows, macOS and Linux builds, including the auto-updater.
• Mobile app - iOS and Android.
• CLI - the dosya command line tool, including its sync engine.
• Public repositories - our SDKs and CLI source under github.com/dosya-dev.

5. Out of Scope

These will be closed without a reward. Please do not send them:

• Denial of service, volumetric attacks, and load or stress testing of any kind.
• Social engineering of our team, our users, or our vendors. Phishing, pretexting, and support-desk manipulation are all off limits.
• Physical attacks, and anything targeting an employee's personal accounts or devices.
• Output from an automated scanner with no proof of concept and no demonstrated impact.
• Missing security headers, cookie flags, or TLS configuration nits with no working exploit.
• Self-XSS, and issues that require the victim to paste attacker-supplied code into their own console.
• Email configuration best practices such as SPF, DKIM or DMARC hardening.
• Clickjacking on pages with no state-changing action.
• Vulnerabilities in third-party services we depend on but do not control, including Cloudflare, Stripe, and Resend. Report those to their own programs.
• Issues that only affect an end-of-life browser or an unpatched operating system.
• Username or email enumeration on endpoints where the behaviour is intentional.
• Reports that consist only of a version number and a CVE, with no evidence the CVE is reachable here.

6. Rules of Engagement

Test against your own account and your own data. Specifically:

• Create your own account and workspace to test against. Free accounts are fine, and you can register as many as you reasonably need.
• Never access, modify, or delete another user's data. If a bug gives you access to someone else's files, stop, take the minimum evidence needed to prove it, and report it. Do not browse further.
• Do not exfiltrate data. A screenshot of a filename is proof. A copy of the file is not necessary.
• No destructive testing. No mass deletion, no quota exhaustion, no attempts to degrade service for other users.
• Stay within our rate limits, and do not automate high-volume scanning against production.
• Delete any test data, test accounts, and uploaded files when you are finished.
• Do not use a finding for anything beyond demonstrating it.
• Give us a reasonable window to fix the issue before disclosing it publicly. Ninety days is our default, and we are usually much faster. If you want to publish, tell us and we will agree a date.
• One issue per report. If you find a chain, describe the chain in a single report rather than filing each link separately.

7. Safe Harbor

Section 6 of our Terms of Service ("Acceptable Use Policy") prohibits circumventing or interfering with the security features and limits of the service. This program is an explicit, authorized exception to that clause.

If you make a good faith effort to follow the rules of engagement above, then:

• We will not pursue or support legal action against you for your research.
• We will not report you to law enforcement, or treat your testing as a breach of our Terms.
• We will not suspend your account for security testing carried out within these rules.
• If a third party brings a claim against you for research that stayed inside this policy, we will make it known that your activity was authorized.

This protection does not extend to accessing other users' data beyond what is needed to prove a bug, to extortion or a threat to disclose, or to anything in the out-of-scope list. If you are unsure whether something is allowed, ask us first at security@dosya.dev. We would much rather answer a question than argue after the fact.

8. What Happens After You Submit

• Within 5 business days: we acknowledge your report and let you know it reached a person.
• Within 14 days: we give you a triage decision - accepted with a severity, duplicate, or out of scope with a reason.
• On acceptance: we agree a reward and a payment method with you, and tell you roughly when the fix will ship.
• On the fix: we let you know it has shipped, and add you to the Hall of Fame if you want to be named.

These are honest numbers for a small team, not a marketing promise. If something is critical and actively exploitable, say so in the title and we will move on it immediately.

9. Hall of Fame

Researchers who have reported a valid vulnerability to us, with their permission to be named.

No entries yet. This program is new - be the first.

10. Submit a Report

Use the form below. If you would rather use email, or you want to send something you are not comfortable putting in a web form, write to security@dosya.dev instead - it reaches the same place.

Please do not attach files. Paste your reproduction steps into the description, and link to a video or writeup if you have one.