Bug bounty

Found a security flaw in DeskOS? Email bugbounty@deskos.net with the steps to reproduce it. Test only on a workspace you own, take nothing that is not yours, and give us a reasonable chance to fix the issue before you talk about it publicly. Do that and we will treat your research as authorised, keep you updated while we fix it, and credit you if you want to be named.

If you are not sure whether something is in scope, ask first. A short question to bugbounty@deskos.net is always cheaper than an assumption.

DeskOS runs the operating layer of physical workspaces. A single account can hold a building’s member list, its invoices and payment records, its visitor log, and the credentials that open its doors. Every operator runs on their own workspace inside a shared platform, so the boundary between one customer and the next is the single most important security property we have.

We would much rather hear about a weakness from you than read about it in an incident report. This page sets out how to look for one without putting a real operator, or yourself, at risk.

The systems below are ours to fix, and findings against them are eligible:

• deskos.net and its pages, including this marketing site, the documentation and the blog.
• Operator workspaces on *.deskos.net, but only a workspace you own or have written permission from its operator to test. This covers both the admin console and the member portal.
• The DeskOS API at oscar.nova.deskos.net, including authentication, tokens, and any tenant-scoped endpoint.
• The DeskOS mobile apps for members and the DeskOS Hub app for operators, on Android and iOS.
• Companion software you run yourself as an operator: the front desk kiosk, meeting room panels, the print agent and the access control bridge, in your own installation.

What we care about most

These classes get the fastest response and the largest rewards, because they map to the damage a real attacker would do:

• Tenant isolation. Reading or writing data belonging to another organisation or another campus, in any form.
• Authentication and sessions. Account takeover, token forgery or replay, refresh and rotation abuse, password reset flaws, authentication bypass.
• Privilege escalation. A member reaching admin functionality, or a staff account acting outside the permissions it was granted.
• Money. Tampering with an invoice, a price, a payment amount or a payment status, forging a gateway callback, or reaching another organisation’s financial records.
• Physical access. Opening a door, issuing or extending a credential, or forging a visitor pass or check-in you are not entitled to.
• Server-side classes. Remote code execution, injection, deserialisation, server-side request forgery, path traversal, and unauthenticated file access.
• Stored data exposure. Invoices, signed agreements, identity documents, member photographs, attendance and visitor records reachable without authorisation, including through predictable or unsigned file URLs.

Systems you must not test

• Any workspace belonging to another operator, and any data belonging to a real member, company or visitor.
• Third party services we use but do not operate, including payment gateways, messaging and email providers, cloud and hosting consoles, and identity providers. Report those through the vendor’s own program. If their flaw is exposed through us, we do want to hear about that part.
• Physical premises, staff, members, and access control hardware installed at a customer site that is not yours.
• Our corporate systems, employee accounts and internal tooling.

Findings that do not qualify

These are either accepted risks, someone else’s problem, or reports we cannot act on. We may still fix them, but they earn no reward:

• Missing security headers, cookie flags or TLS configuration with no demonstrated exploit.
• Email configuration findings such as SPF, DKIM or DMARC records, without a working spoofed message delivered to a real inbox.
• Absent or weak rate limiting with no demonstrated impact, and any form of brute force conducted at volume.
• Denial of service, resource exhaustion, load testing, and anything that degrades service for other users.
• Self-XSS, clickjacking on pages with no state-changing action, and content or text injection with no script or HTML execution.
• Open redirects and CSRF on actions with no security consequence.
• Software version disclosure, banner grabbing, public directory listings, and outdated dependencies with no working proof of concept against our systems.
• Account existence disclosure on login or signup forms, unless it reveals the membership of an organisation to an outsider.
• Findings that require a rooted or jailbroken device, a physically unlocked device, a compromised operating system, or an attacker who already controls the victim’s browser.
• Missing certificate pinning or missing obfuscation in the mobile apps, and static analysis output with no exploit path.
• Social engineering or phishing of our staff, our customers or their members.
• Raw output from an automated scanner with no manual validation, and reports produced by a tool or a model without a reproduction that works.
• Issues in a self-managed deployment running a version we have already patched.
• Behaviour that is documented and intended, such as a workspace administrator being able to see their own members’ data.

Testing that follows these rules is authorised. Testing that does not is simply an intrusion, and we will treat it as one.

• Test on your own workspace. Use a trial workspace you created, or ask us for a sandbox. Email bugbounty@deskos.net and we will set one up for you at no cost, with test data only.
• Use only accounts you control. If you need a second account to prove a cross-account issue, create it yourself.
• Stop at proof. As soon as you can demonstrate the issue, stop. Do not enumerate further records, and do not widen the blast radius to make the report look better.
• Never touch data that is not yours. Do not access, modify, delete, download in bulk, or retain any real customer or member data. If you come across it by accident, stop immediately, do not save a copy, and tell us in the report what you saw.
• Leave nothing behind. No backdoors, no persistence, no pivoting to other systems. Remove any accounts, files or records you created, and tell us about anything you could not clean up.
• Keep automated tools on a leash. Throttle scanners, avoid destructive payloads, and never run them against production data belonging to an operator. Sending X-Bug-Bounty with your handle as a request header helps our team tell your traffic apart from a real attack.
• Do not disrupt. No changes to live bookings, invoices, doors or member records outside your own sandbox.
• Keep it confidential. Do not disclose the issue, publicly or privately, until we have fixed it or 90 days have passed from your report, whichever comes first. If a fix needs longer, we will explain why and agree a date with you. Talk to us before publishing anything, and never publish customer data.
• One issue per report. Separate findings belong in separate emails, so each can be tracked and rewarded on its own.
• Stay within the law. Nothing in this policy permits activity that is illegal where you are, or where our systems are.

If you make a good-faith effort to follow this policy while researching a vulnerability, we will treat your research as authorised and we will not pursue or support legal action against you for it. That includes claims under computer misuse and anti-hacking legislation, and claims relating to circumventing technical protections for the purpose of your research. We will not report you to your internet or hosting provider, and if a third party brings an action against you for work that followed this policy, we will make it known that you were authorised.

This protection ends where the rules do. It does not cover accessing or retaining another customer’s data, disrupting service, extorting us, disclosing an issue before we agreed a date, or using a finding for anything other than reporting it.

Acting in good faith includes asking when you are unsure. Send scope questions to bugbounty@deskos.net and we will answer before you start.

Email bugbounty@deskos.net. There is no form and no account to create. Reports in English are easiest for us to triage quickly.

A report we can act on straight away includes:

1. A one-line summary and the severity you would give it.
2. The exact target: URL, API endpoint and HTTP method, or the app screen, and whether it is the admin console, the member portal, the public site or the API.
3. The workspace and accounts you used, including the workspace slug and the role of each account.
4. Numbered steps to reproduce, written so someone who has never seen the bug can follow them.
5. A proof of concept: the request and response, a minimal payload, or a short screen recording. Redact anything sensitive you happened to see.
6. The impact in plain terms. What does an attacker end up with, and who does it hurt.
7. How you would like to be credited, or that you would rather not be named.

Please do not include real personal data in your report. A redacted screenshot that proves the point is worth more to us than a database dump, and sending us other people’s data creates a second problem on top of the first.

If you believe an issue is being actively exploited, or that customer data is exposed right now, say so in the subject line and we will treat it as an incident rather than a report.

These are the targets we work to. They are working days, and we will tell you as soon as we know a particular case will take longer.

• Acknowledgement, within 3 working days. A human confirms we have your report.
• Triage, within 7 working days. We tell you whether we could reproduce it, whether it is in scope, the severity we assigned, and whether it duplicates an existing report.
• Progress updates, at least every 14 days while the issue is open.
• Fix targets by severity. Critical issues within 7 days, high within 30, medium within 90, and low in a scheduled release. Anything that exposes customer data across workspaces is worked on immediately.
• Confirmation and close. We tell you when the fix is live and, where we can, invite you to verify it.

We rate severity using CVSS as a starting point and then adjust for what the issue means in practice on this platform. Anything that crosses the boundary between two operators, touches money, or opens a door is treated more seriously than its base score suggests.

Every valid report gets a thank you, and we are glad to name you in the acknowledgements below. Beyond that, rewards are discretionary and decided case by case. What moves the number:

• Severity and real-world impact, weighted toward tenant isolation, payments, authentication and physical access.
• The quality of the report. A clear reproduction and a working proof of concept save us hours and are valued accordingly.
• Novelty. A new class of issue is worth more than another instance of one we already know about.

The first person to send a reproducible report of a given issue is the one who gets the reward. Duplicates and variants of an issue already in our queue are acknowledged but not rewarded separately.

Not eligible for a reward:

• Current and former employees and contractors of Tech Dreams Pvt Ltd, and their immediate families.
• Anyone we are not legally permitted to pay, including residents of sanctioned jurisdictions.
• Anyone who broke the rules of engagement while finding the issue.

Where a reward is paid, you are responsible for any tax that applies in your country, and we may need identity and payment details before we can send it.

This program is new, and the wall is empty. Researchers who report a valid issue will be listed here, with their permission, along with the month of the report. Tell us in your email how you would like to be credited, and let us know if you would rather stay anonymous.

This page is for security research. If you have found a bug that is not a security issue, or something in your workspace looks wrong, contact support@deskos.net or your usual support channel, and it will reach the right team faster.

If you suspect an account of yours has been compromised, or you have seen data in your workspace that should not be there, write to bugbounty@deskos.net and mark the subject urgent.

We keep your report, your correspondence and the contact details you send us for as long as we need them to fix the issue, pay or credit you, and keep a record of what happened. We share the technical detail internally with the people fixing it, and with an affected customer where we are obliged to tell them. We do not publish your identity without your agreement.

Our privacy policy covers how we handle personal data generally.

Submitting a report does not create employment, a contract, a partnership or any other relationship between you and Tech Dreams Pvt Ltd, and it does not entitle you to a payment. By reporting, you give us permission to use the contents of your report to investigate, fix and communicate about the issue, and you confirm that you found it in the course of research permitted by this policy.

We may update this policy at any time. The version published here applies to research carried out while it is live, and material changes will move the revision date at the foot of this page.

Security reports, scope questions and sandbox requests all go to bugbounty@deskos.net. It reaches our security team directly. Please do not send sales enquiries or support tickets to this address, as it will only slow you down.