Overview
Programs specify prohibited testing — techniques and actions that are forbidden regardless of scope. Knowing and avoiding them is essential to safe, compliant participation. This lesson covers prohibited testing.
Learning objectives
- Identify commonly prohibited testing techniques.
- Explain why they are prohibited.
- Avoid prohibited actions during testing.
Core concept
Prohibited testing covers techniques and actions a program forbids because they risk harm or exceed acceptable bounds. Commonly prohibited: denial-of-service (DoS) and stress/load testing (risk outages), social engineering of staff or users (harms people, legal sensitivity), physical attacks, automated scanning beyond set limits (can overwhelm systems), testing that could access, modify, or destroy real user data, and any action that could harm availability or real users. These are forbidden regardless of whether the asset is in-scope — the technique itself is off-limits.
How it works
The researcher reads the prohibited-testing rules and avoids those techniques entirely, even on in-scope assets. For example, they do not attempt DoS (which could take down a service), do not social-engineer employees, keep automated scanning within allowed limits, and never access or alter real user data (using test accounts and minimal proof instead). If demonstrating a vulnerability would require a prohibited action or risk harm, the researcher finds a safe way to prove it minimally, or reports it without crossing the line. Prohibited-testing rules are hard limits that protect the organization and its users.
Practical example
A program prohibits DoS, social engineering, and automated scanning above a set rate, and forbids accessing real user data. A researcher testing an in-scope application avoids any load/DoS testing, does not attempt to phish or manipulate staff, throttles their scanning to the allowed rate, and — when demonstrating an access-control flaw — uses test accounts and captures minimal, redacted proof rather than accessing real users' data. They proved the issue without any prohibited action, staying safe and compliant.
Cybersecurity relevance
Prohibited-testing rules exist to prevent real harm — outages (DoS), harm to people (social engineering), system overload (excessive automation), and privacy violations (accessing real user data). Violating them can damage the organization and users, void the researcher's authorization, and lead to bans or legal action, even on in-scope assets. Avoiding prohibited techniques (and proving findings safely with test accounts and minimal proof) is essential responsible-testing discipline, mirroring the prohibited-technique and data-handling rules from the ethical-hacking path. It protects everyone and sustains the bug bounty relationship.
Common mistakes
- Attempting DoS or excessive automated scanning, risking outages.
- Social-engineering staff/users or accessing real user data to "prove" an issue.
- Assuming prohibited techniques are okay on in-scope assets — the technique itself is forbidden.
Key takeaways
- Prohibited testing covers forbidden techniques regardless of scope: DoS/stress testing, social engineering, physical attacks, excessive automated scanning, and accessing/modifying real user data.
- They are prohibited because they risk harm to systems, people, and user privacy; violating them voids authorization and can cause real damage.
- Avoid prohibited techniques entirely and prove findings safely (test accounts, minimal redacted proof) — essential responsible-testing discipline mirroring rules of engagement.
Check your understanding
- Why are DoS and social engineering commonly prohibited even on in-scope assets?
- How can a researcher demonstrate a data-access vulnerability without accessing real user data?