Vulnerability disclosure

How to report

Email security@coderook.com. There is no form and no account required.

Useful things to include, roughly in order of usefulness:

• What an attacker can do that they should not be able to do.
• The steps to reproduce it, including any request you sent.
• Which URL or endpoint, and roughly when you tried it.
• Whether you stopped at proving it, or went further.

Do not include live user data, and do not send us someone else's content as evidence. If proving the issue required reaching data that is not yours, say so and describe it rather than attaching it.

What is in scope

• coderook.com and api.coderook.com
• The CodeRook CLI and desktop application
• Anything that lets one account reach another account's private content, or reach content whose owner has restricted it
• Authentication, session handling, two-factor enrolment and recovery
• Billing and subscription handling

What is out of scope

Not because these do not matter, but because a report about them tells us something we already know.

• Missing headers or configuration findings with no demonstrated impact, including automated scanner output on its own.
• Rate limits being reachable. The request budgets on the per-version file routes are intentional and documented — hitting them is the system working.
• That public content can be read by anything, including machines. Project access settings stop automation, not people; we say so plainly on the AI page.
• Denial of service through volume, and anything requiring physical access to a user's device or their existing credentials.
• Social engineering of us, our users, or our providers.

You may test against the live service

There is no staging environment to send you to, and asking first would only mean waiting for a reply before you could look at anything. Test against production. The conditions below are what keep that reasonable — they are about other people's data and other people's uptime, not about protecting us from finding out.

We will not come after you

If you are acting in good faith and stay within this policy, we will not pursue legal action against you, will not report you to law enforcement, and will not ask your employer or your hosting provider to act against you. If somebody else brings a claim about research that followed this policy, we will say publicly that it was authorised.

Good faith means what it sounds like: you were trying to find a problem and tell us, you stopped once you had proof, and you did not take anything with you. Accidentally reaching further than you meant to does not void this — tell us what happened and it stays covered.

What is not covered is using a finding rather than reporting it: extortion, selling it on, holding it back for leverage, publishing data you reached, or deliberately damaging the service or the people on it.

What we ask while you are testing

• Use your own accounts and your own projects. If a test needs two parties, make two accounts.
• Stop at proof. Read enough to confirm the issue, then stop — do not collect, retain, or publish anything that is not yours.
• Do not degrade the service for other people. If demonstrating an issue requires volume, describe it instead and we will test it ourselves.
• Give us a reasonable chance to fix it before publishing. We will not ask you to stay quiet indefinitely.

What you can expect from us

• A first reply within three days. From a person, not an autoresponder, saying whether we have understood it and what happens next. If three days pass with nothing, assume it went astray and send it again.
• We will tell you whether we think it is a real issue rather than leaving you guessing.
• We will tell you when it is fixed, and we will not quietly patch it and stop replying.
• Credit, if you want it. Say so in your report and tell us how you would like to be named. If you would rather stay anonymous, that is fine too.

There is no paid bounty. That is a deliberate choice rather than an oversight — a reward programme this service could not review properly would waste your time as well as ours.

If a breach affects users

Where a security incident is likely to cause serious harm to the people affected, Australia's Notifiable Data Breaches scheme requires notification to those individuals and to the Office of the Australian Information Commissioner. We would tell affected users directly, and we would say what we knew at the time rather than waiting until the picture was flattering.