Responsible Disclosure and Ethics
The same skills are a career or a crime. Scope and consent are the line.
What you will learn
- -State what makes testing legal versus illegal
- -Read a scope and stay inside it
- -Run a coordinated disclosure without burning yourself
Every technique in this module is neutral. What decides whether you are a security professional or a defendant is one thing: . This lesson is the least flashy and the most important. it wrong and the skills stop mattering.
The line is consent, and it is legal
In the United States the relevant law is the Computer Fraud and Abuse Act (CFAA). Similar laws exist worldwide, like the UK Computer Misuse Act. The common thread is that accessing a computer without authorization is a crime, full stop. Good intentions are not a defense. Finding a real bug is not a defense. Never having caused damage is not a defense. The question a court asks is simply whether you had permission.
So the rule is blunt. You test systems you own, systems you have written permission to test, or deliberately vulnerable practice targets. Nothing else.
Scanning or exploiting a live third-party 'just to help' or 'just to see' is illegal even if you report it politely afterward. If it is not yours and no one authorized it, you do not touch it. There is no gray area here worth your freedom.
Where you are allowed to practice
You do not need someone else's to build real skill:
- Your own lab: local VMs you spin up and attack. Total freedom, zero .
- Practice platforms: Hack The Box, TryHackMe, PortSwigger Web Security Academy, and CTFs exist precisely so you can attack them.
- Bug bounty programs: platforms like HackerOne and Bugcrowd where companies publish an invitation to test. That invitation is your authorization, and it has boundaries.
Read the scope like a contract
A bug bounty or pentest engagement comes with a : the exact you may test and the ones you may not. This is not paperwork to skim. It is the document that keeps you legal.
- In scope: the specific , IP ranges, or apps listed. Test these.
- Out of scope: everything else, often including subdomains, third-party integrations, and physical or social-engineering attacks.
- Rules of engagement: forbidden actions like denial-of-service, automated scanning limits, and what to do the moment you find real user data.
If a target is not explicitly in scope, treat it as forbidden. 'Not mentioned' means no, not maybe.
The moment an exposes actual customer records or you can reach production data, stop escalating. Prove the with the minimum needed, do not download or alter data, and report. Going further to see how deep it goes is how a valid finding becomes a crime.
Coordinated disclosure
You found a real bug in an authorized target. Now report it well:
- Document it clearly: what the bug is, exact steps to reproduce, and the concrete . A report a developer can act on is worth ten vague ones.
- Report privately through the program's channel or the vendor's security contact. Give them the details, not the public.
- Give them time to fix. The industry norm is a disclosure window, commonly around 90 days, before any public write-up. Agree on it.
- Publish only after a fix or after the agreed window, and only if the program allows it. Never drop a working exploit on an unpatched system.
This is coordinated disclosure: the researcher and the vendor work the timeline together. The alternative, dumping a live exploit publicly, endangers real users and torches your reputation.
A bug bounty lists app.company.com as in scope. You find a serious flaw on admin.company.com, a subdomain not mentioned. What do you do?
In coordinated disclosure, when is it acceptable to publish a working exploit publicly?
You report privately, give the vendor time to patch (commonly around 90 days), and only publish after the fix ships or the agreed window closes, if the program permits it. Never before.