Images are AI-generated illustrations, not documentary photographs or product screenshots.
Ethical hacking permission: permission comes before the tools
Ethical security testing begins with authorization, not with the ability to access a system. A public website, an exposed endpoint or a company logo does not grant permission to test it. Before doing anything that could affect a service, establish who owns the relevant asset and who can authorize the work. If that authority is unclear, stop. This guide concerns responsible preparation and does not provide attack instructions.
Write down the exact scope
Specify the permitted assets, test accounts, dates, methods and limits. A domain name may include third-party infrastructure that the organization does not control. HackerOne’s own security policy explicitly excludes third-party assets outside its control, illustrating why authorization cannot simply be assumed across a connected system. That policy governs its own program; it is not general permission to test other programs hosted on the platform. Read each organization’s current policy separately.
Agree on prohibited activity
Discuss availability risks, access to customer information, destructive changes, social engineering and other sensitive activities. Some work may be out of scope even if it is technically related to an authorized asset. A contract or program policy should describe relevant restrictions. Do not infer approval from silence, broad marketing language or a bounty listing. If a planned step could exceed the agreed boundary, ask the authorized contact before proceeding.
Set a data-handling plan
Determine what evidence you may collect, where it will be stored, who may read it and when it must be deleted. Use the minimum information needed to explain a finding. Do not browse private records merely to make a report more dramatic. If unexpected sensitive data appears, follow the owner’s policy and stop when required. HackerOne’s own policy instructs researchers to stop and contact it when sensitive information is inadvertently obtained.
Create a communication and stop procedure
Name the technical contact, backup contact and escalation path. Agree on what happens if a service slows down, an account locks or an unintended change occurs. A responsible tester should be able to stop quickly and explain the current state. Keep accurate notes of permitted work so that the owner can distinguish your activity from an unrelated incident. Do not continue because you are close to producing an impressive result.
Report clearly without exaggeration
A useful finding describes the affected asset, the observed behavior, relevant conditions and a proportionate explanation of impact. Distinguish what you verified from what is only plausible. Protect credentials and personal information in screenshots and supporting files. Follow the disclosure process and allow the owner to assess and fix the issue. Publication rights and bounty eligibility are separate questions from testing permission; neither should be assumed.
Learn in environments you are allowed to use
If you do not have a written scope, use purpose-built training environments, your own isolated lab or a program that explicitly authorizes the relevant activity. Review the rules every time. Security expertise includes judgment about boundaries, not just technical skill. Laws and contracts vary by jurisdiction, and this article is not legal advice. When permission is ambiguous, the professional action is to clarify it rather than experiment on someone else’s system.
Sources and further reading
HackerOne: its own security testing policy and scope
Related reading
Hiring Cybersecurity Consulting Services: Scope, Evidence and Boundaries
Security+ Certification: Plan Study Around the Current Objectives