# The rules of legal hacking Canonical: https://hackergpt.org/legal-hacking/ Hacking is legal when the owner of the system has said yes. Without that yes, the same actions can be a crime. This page explains where that line is, why it sits there, and the habits that keep you on the right side of it while you learn. **Not legal advice.** We are not lawyers. This page is general educational information only. It is not legal advice and not a lawyer's advice. Laws differ from country to country and change over time, so for your own situation, talk to a qualified lawyer where you live. ## The short version - Get **permission** before you test anything. - Test **only your own websites and systems**, or targets whose owner has given you **written permission**. - **Never** hack or scan a website without permission, not even to look, not even to help. - Be **accurate**: stay inside the agreed scope, test only what you were allowed to test, and report what you find truthfully. Everything below is the detail behind those four lines: who can give permission, what it has to say, what you must not do even with it, and what to do when you find something. ## 1\. Get written permission from someone who can give it The computer-misuse laws covered below are built around one idea: access or actions that are not authorised. The UK Computer Misuse Act spells out what that means: an act is unauthorised if the person doing it is not the one entitled to decide whether it may be done, and does not have consent from someone who is ([Computer Misuse Act 1990, s. 17(8)](https://www.legislation.gov.uk/ukpga/1990/18/section/17)). The EU directive on attacks against information systems uses the same test: conduct is "without right" when it is not authorised by the owner or another right holder of the system ([Directive 2013/40/EU, Art. 2(d)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013L0040)). So the common rule is not just "get permission", but "get permission from the person entitled to give it". That is often less obvious than it looks: - Owning a domain name or an account is not the same as owning the server. Your site may run on a host, a cloud platform or a SaaS product that belongs to someone else. - A client can authorise testing of what they control. They cannot authorise you to test their hosting provider, their payment processor or any third-party service they use. - Working for a company does not by itself authorise you to test its systems. Testing is a task someone with authority has to give you. - Permission is specific. A yes for one site, one week or one technique is not a yes for the next. Get it in writing. A verbal yes is easy to misremember and impossible to show later. A written authorisation names who is granting it and their role, who is testing, what is in scope, and when. It is what separates a test from an attack if anyone asks. ## 2\. Agree the scope and the rules of engagement Permission is only as useful as its edges. Professional testing guidance such as [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) starts with a planning phase in which the scope and the rules of engagement are agreed before any testing. Even when the site is your own, write down: - **Targets**: the exact hosts, URLs, IP addresses, apps and accounts. - **Techniques**: what is allowed, and what is not (for example no denial of service, no social engineering, no testing of payment flows). - **Time window**: dates and hours, and the time zone. - **Contacts**: who to call when something breaks or when you find something serious, and how to reach them quickly. - **Data**: what you may look at, what you must not keep, and how findings are sent. The common rule is simple: **anything not listed is out of scope.** A subdomain you discover, a linked service or a new IP address is not covered because it looks related. Ask, and wait for a written yes. ## 3\. Respect third parties and cloud providers Most websites sit on infrastructure that belongs to someone else, and that someone has rules of their own. Read them before you test, because the owner's permission does not override them. - **AWS** lets customers test their own AWS infrastructure without prior approval for a list of permitted services, and prohibits activities such as denial of service, flooding and DNS zone walking ([AWS penetration testing policy](https://aws.amazon.com/security/penetration-testing/)). - **Microsoft** requires testing of its cloud to stay within your own tenant or assets you are explicitly authorised for, and prohibits denial-of-service testing and accessing other customers' data ([Microsoft Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement)). - **Google Cloud** does not require you to notify it before testing your own project, but you must follow its Acceptable Use Policy and Terms of Service and make sure your tests only affect your own projects ([Google Cloud security FAQ](https://support.google.com/cloud/answer/6262505)). - **Shared hosting** puts many people's sites on the same server and IP address. Scanning that IP means scanning their sites too, and you have no permission for those. - **Embedded services**, such as payment widgets, login providers, analytics and chat, belong to their vendors. If they are in scope at all, it is under the vendor's own policy, not your client's. Providers change these policies; read the current version each time rather than relying on a summary, including this one. ## 4\. Do no harm Permission to test is not permission to damage. The laws treat harm as its own offence: the UK Computer Misuse Act covers unauthorised acts that impair a computer's operation or the reliability of its data, including when done recklessly and even if the impairment is temporary ([s. 3](https://www.legislation.gov.uk/ukpga/1990/18/section/3)), and the EU directive asks member states to criminalise serious hindering of a system and deleting or altering its data without right ([Directive 2013/40/EU, Arts. 4 and 5](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013L0040)). The common rules for testers follow from that: - No denial of service, load or flood testing unless it is explicitly agreed, and on cloud platforms only where the provider allows it. - Do not delete or change real data. Use test accounts and test data, and a staging copy for anything that writes. - No backdoors, implants or persistence beyond what was agreed, and remove what you added when the test ends. - Do not use one finding to move deeper into systems that were not in scope. - If something breaks, stop, tell your contact straight away, and do not resume until they say so. ## 5\. Touch as little data as possible A test often shows you data you were not looking for: customer records, emails, tokens. The common rule is to access the minimum needed to prove a finding, and then stop. - Prove access with the smallest example, such as one record count or one redacted field, not a download. - Do not copy, keep or share personal data, and do not use it for anything. - If you reach data you were not meant to see, stop, tell the owner, delete anything you hold, and say so in your report. Microsoft's testing rules ask for exactly that ([Microsoft Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement)). - Data-protection law still applies during a test. In the EU, the [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) governs the processing of personal data within its scope, and its principles, such as data minimisation in Article 5(1)(c), do not switch off because the processing is part of a security test. ## 6\. Stop at the edge, and report responsibly Two situations need the same reflex: you find something outside your scope, or you find something sensitive inside it. Stop, do not explore further, write down what you saw, and tell the owner through the contact you agreed. When the finding is in a system you were not hired to test, for example a vulnerability you noticed in a product you use, the common practice is coordinated disclosure: - Report privately to the organisation first, through its published policy, its bug bounty programme or the contact in its `security.txt` file ([RFC 9116](https://www.rfc-editor.org/rfc/rfc9116)). - Give it reasonable time to fix the issue before anything is published ([CISA coordinated vulnerability disclosure](https://www.cisa.gov/coordinated-vulnerability-disclosure-process), [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). - Never ask for money in exchange for the details or for staying quiet. OWASP warns that demanding payment as a condition of disclosure may constitute extortion, and the US Computer Fraud and Abuse Act separately covers extortion threats involving computers ([18 U.S.C. § 1030(a)(7)](https://www.law.cornell.edu/uscode/text/18/1030)). - Never publish or dump the data you saw. A disclosure describes the weakness and its fix; it does not prove the point with someone's records. Reporting a finding is not permission to have looked for it. Coordinated disclosure is how you handle what you found; it does not make unauthorised testing authorised. ## 7\. Follow each bug bounty programme to the letter Bug bounty programmes are a way organisations give the public permission to test, but only on their terms. Each programme publishes a policy with its scope, its rules and its disclosure conditions, and HackerOne tells researchers to review that policy carefully before participating, because it may supersede the platform's own guidelines ([HackerOne disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)). - Having an account on a bug bounty platform is not blanket permission. Each programme is its own permission, for its own listed targets. - Safe-harbour terms protect testing that stays inside the programme's scope and rules. OWASP notes that stepping outside them may be a criminal offence ([OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)). - A programme can only authorise systems its owner controls. A third-party service linked from an in-scope site is not in scope because of the link. - Disclosure follows the programme's rules. On HackerOne, private programmes are subject to non-disclosure by default. ## 8\. Keep records If anyone ever asks what happened, your records are the answer. Keep, and store securely: - The written permission, with who signed it and when. - The scope and rules of engagement, including any changes agreed during the test, in writing. - A log of what you did: dates and times, the source IP addresses you tested from, tools and commands, and which targets each touched. - Your findings with their evidence, and a note of what data you saw and when you deleted it. Logs also make you better: a finding you can reproduce from your notes is one the owner can fix. ## 9\. The laws, briefly A short, simplified overview of three well-known laws, to show where the line usually sits. It is not a complete statement of any of them; follow the links to the text itself. ### United States: Computer Fraud and Abuse Act The CFAA makes it an offence to intentionally access a computer without authorisation or to exceed authorised access and thereby obtain information, to cause damage to a protected computer, and to make extortion threats involving computers, among other things ([18 U.S.C. § 1030](https://www.law.cornell.edu/uscode/text/18/1030)). The Justice Department tells federal prosecutors not to charge conduct that was solely good-faith security research ([Justice Manual 9-48.000](https://www.justice.gov/jm/jm-9-48000-computer-fraud)), but that is a charging policy, not a change to the law, and it does not bind states, civil claims or other countries. ### United Kingdom: Computer Misuse Act 1990 Section 1 makes unauthorised access to computer material an offence when the person knows the access is unauthorised ([s. 1](https://www.legislation.gov.uk/ukpga/1990/18/section/1)). Section 3 covers unauthorised acts that impair a computer's operation ([s. 3](https://www.legislation.gov.uk/ukpga/1990/18/section/3)), and section 3A covers making, supplying or obtaining tools intending or believing that they will be used for one of those offences ([s. 3A](https://www.legislation.gov.uk/ukpga/1990/18/section/3A)). Section 17 defines what "unauthorised" means ([s. 17](https://www.legislation.gov.uk/ukpga/1990/18/section/17)). ### European Union: Directive 2013/40/EU The directive on attacks against information systems requires EU member states to make illegal access, illegal system interference, illegal data interference, illegal interception, and tools made for those offences criminal offences when done intentionally and without right, at least for cases which are not minor ([Directive 2013/40/EU, Arts. 3 to 7](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013L0040)). Each member state writes this into its own national law, so the exact offences and penalties differ by country. The directive also notes that tools made for legitimate purposes, such as testing the security of systems, are not the target of the tools offence. ### Everywhere else Many other countries have similar computer-crime laws, and the EU directive itself builds on the Council of Europe's 2001 Convention on Cybercrime, which other countries outside the EU have joined as well ([Directive 2013/40/EU, recital 15](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013L0040)). Where you are, where the target is and where its owner is can all matter. One point holds across all of them: these laws look at what was done to a system and whether it was authorised, not at which tool did it. Running a scanner, an active reconnaissance tool or an AI agent against a target is testing that target. Reading public records, such as DNS or certificate transparency logs, is a different activity from probing the system itself, but once a tool starts sending requests to the target, treat it as a test that needs permission. ## 10\. Where to practise instead You do not need anyone's production site to learn. Practise on targets whose owners have said yes in advance: - **Your own lab**: virtual machines and containers on your own computer, or your own site on hosting whose terms allow testing. - **Deliberately vulnerable apps** such as OWASP Juice Shop, which you can run yourself. - **[CyberGym](https://cybergym.hackergpt.app)**, a hosted, deliberately vulnerable web shop published by HackerGPT for training and CTFs. - **CTF competitions and training platforms**, within each one's own rules. Our article [Where to practice hacking legally](https://hackergpt.org/blog/practice-hacking-legally/) compares these options and walks through a first session on CyberGym. ## 11\. How this applies to HackerGPT HackerGPT's tools test the targets you point them at, so every rule above applies to them in the same way it applies to you: - **[AppMap](https://hackergpt.org/features/appmap/)** crawls an app and lists its API endpoints. Run it only on an app you own or have written permission to test. - **[CTF Mode](https://hackergpt.org/features/ctf-mode/)** solves CTF challenges. Use it on your own site, on CyberGym, or on a CTF you are entered in. - **Scans and agent runs** send real requests to the target. They are tests, and they need the same permission and scope as a test you run by hand. A tool cannot give you permission. You are the one who chooses the target, so the permission has to be yours before the first request. If you do not have a site of your own yet, start on CyberGym. ## Before any test: the permission checklist Answer every question before the first request. If any answer is no or "not sure", do not start. 1. Do I own this system, or do I have permission from the person entitled to give it? 2. Is that permission in writing, with the name and role of whoever granted it and the date? 3. Do I have the exact list of targets: hosts, URLs, IP addresses and accounts? 4. Do I know which techniques are allowed and which are excluded? 5. Do I know the time window I may test in? 6. Have I checked the hosting, cloud and third-party providers' testing policies? 7. Do I have a contact to call if something breaks, and do I know how to stop? 8. Do I know what I will do if I see personal or sensitive data? 9. Am I logging what I do, from where and when? 10. Do I know how, and to whom, I will report what I find? ## FAQ ### Is it legal to learn hacking? Learning is generally legal: reading, courses, labs and practice on targets that invite you. What computer-misuse laws such as the CFAA and the Computer Misuse Act target is access to or interference with systems without authorisation. Some laws, such as section 3A of the UK Computer Misuse Act, also cover making or supplying tools intended for one of those offences, so keep your tools for authorised work. ### Is it illegal to scan a website without permission? It can be. A scan sends requests to someone else's system, and depending on the country and what the scan does, that can fall under computer-misuse law, and it can break the site's or your provider's terms. The safe rule is the simple one: scan only your own sites, sites whose owner has given you written permission, or practice targets that exist to be scanned. ### Does a verbal OK count as permission? It is far weaker than a written one. A verbal yes is easy to misunderstand, rarely says what is in scope, and cannot be shown to anyone later. The common practice is to get permission in writing, from someone entitled to give it, before you start. ### I found a vulnerability by accident. What should I do? Stop, do not dig further, and do not keep any data you saw. Then report it privately to the organisation through its disclosure policy, bug bounty programme or security.txt contact, and give it time to fix it. Never ask for payment in exchange for the details. ## Keep learning - [Where to practice hacking legally: CyberGym and other targets](https://hackergpt.org/blog/practice-hacking-legally/) - [What is penetration testing?](https://hackergpt.org/learn/penetration-testing/) - [What is a deliberately vulnerable app?](https://hackergpt.org/learn/deliberately-vulnerable-app/) - [How to pentest your own website with an AI agent](https://hackergpt.org/blog/how-to-pentest-your-own-website/) ## Sources Each source was read on 27 October 2026. - [18 U.S.C. § 1030, Computer Fraud and Abuse Act (Cornell LII)](https://www.law.cornell.edu/uscode/text/18/1030) - [US Department of Justice, Justice Manual 9-48.000: Computer Fraud and Abuse Act](https://www.justice.gov/jm/jm-9-48000-computer-fraud) - [Computer Misuse Act 1990, section 1 (legislation.gov.uk)](https://www.legislation.gov.uk/ukpga/1990/18/section/1) - [Computer Misuse Act 1990, section 3](https://www.legislation.gov.uk/ukpga/1990/18/section/3) - [Computer Misuse Act 1990, section 3A](https://www.legislation.gov.uk/ukpga/1990/18/section/3A) - [Computer Misuse Act 1990, section 17](https://www.legislation.gov.uk/ukpga/1990/18/section/17) - [Directive 2013/40/EU on attacks against information systems (EUR-Lex)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32013L0040) - [Regulation (EU) 2016/679, the General Data Protection Regulation (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [AWS: Penetration testing policy](https://aws.amazon.com/security/penetration-testing/) - [Microsoft: Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement) - [Google Cloud: security and compliance FAQ, penetration testing](https://support.google.com/cloud/answer/6262505) - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final) - [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)](https://www.rfc-editor.org/rfc/rfc9116) - [CISA: Coordinated Vulnerability Disclosure Program](https://www.cisa.gov/coordinated-vulnerability-disclosure-process) - [HackerOne: Disclosure guidelines](https://www.hackerone.com/disclosure-guidelines) **Not legal advice.** We are not lawyers. This page is general educational information only. It is not legal advice and not a lawyer's advice. Laws differ from country to country and change over time, so for your own situation, talk to a qualified lawyer where you live.