1. Read the program before testing
A security program defines the assets an organization permits researchers to test, the vulnerability classes it considers eligible, the restrictions that apply and any reward or disclosure terms.
Read the complete program description before interacting with a target. Scope, exclusions, testing conditions and reporting requirements are all part of the authorization for your research.
Do not assume that an asset is included because it uses the organization's name, shares a domain, redirects to an in-scope host or appears in public documentation. Ownership and authorization are not the same thing.
If a program contains unclear, incomplete or conflicting instructions, pause the affected testing activity and request clarification through the program's designated contact or reporting process.
2. Identify in-scope assets
Scope determines which systems and resources are authorized for testing. Verify the exact asset identifier rather than relying on assumptions about ownership, naming or technical relationships.
- Match the exact hostname, application, API, mobile package, IP address or other asset identifier against the program's scope listing.
- Check whether the listing covers a specific path, endpoint, application version, environment or service rather than an entire domain or infrastructure.
- Review exclusions and any special instructions attached to individual assets.
- Confirm whether subdomains, staging systems, development environments, mobile backends and related infrastructure are explicitly included.
- Check whether third-party services, externally managed infrastructure or integrations are excluded or subject to separate authorization.
- Treat an asset that is not clearly included as out of scope until the organization confirms otherwise.
- Record the relevant scope entry and any applicable restrictions so you can verify your authorization throughout the research process.
3. Understand asset ownership and third parties
An organization may use hosting providers, content delivery networks, payment processors, identity providers, SaaS products and other externally managed services. A service's presence in an organization's application does not automatically authorize direct testing of the service provider.
Distinguish between testing an organization's own application and testing the underlying third-party infrastructure. A vulnerability may be observable through an in-scope application without authorizing attacks against the provider itself.
Do not expand testing to adjacent domains, shared infrastructure, linked applications or external accounts merely because they are technically related to the target.
If a finding appears to originate in a third-party component, document the behavior observed through the authorized target and ask the program how to proceed before testing the third party directly.
4. Read the Rules of Engagement
The Rules of Engagement define the conditions under which research may take place. They supplement the asset scope and can prohibit techniques even when the target itself is explicitly included.
Review the permitted testing methods, prohibited activities, rate limits, account requirements, testing windows, data-handling expectations and incident-reporting instructions.
Program rules may impose stricter limits than your usual testing workflow. Follow the rules applicable to the specific program rather than relying on general assumptions about security research.
- Confirm whether automated scanning is allowed and whether specific tools, concurrency levels or request rates are restricted.
- Check restrictions on denial-of-service testing, resource exhaustion, destructive operations and tests that could affect availability.
- Identify prohibitions on social engineering, phishing, physical access attempts and attacks against employees or customers.
- Check whether password attacks, credential stuffing, brute force, account enumeration or authentication-bypass testing have special restrictions.
- Review rules for creating accounts, using test accounts, accessing personal information and interacting with other users' data.
- Confirm whether exploitation beyond initial verification, persistence, lateral movement or access to additional systems is prohibited.
- Follow any required communication, identification, testing-window or emergency-stop procedures.
5. Distinguish permitted testing from prohibited activity
An asset being in scope does not mean every action against it is allowed. Authorization depends on both the target and the technique used.
Prefer the least intrusive method that can reliably demonstrate the suspected vulnerability. Avoid unnecessary exploitation, destructive changes, broad data collection or actions that could affect other users.
Stop once you have sufficient evidence to establish the issue. Do not access, copy, modify or delete data beyond what is necessary and explicitly permitted for verification.
If a test unexpectedly affects service availability, exposes sensitive information or reaches an unrelated system, stop the affected activity and follow the program's incident-reporting instructions.
6. Check eligible vulnerability classes
Programs may specify which vulnerability types they accept, exclude or prioritize. Review these conditions before spending time on a potential finding.
Common categories include access-control weaknesses, authentication and session flaws, injection vulnerabilities, security misconfigurations, sensitive-data exposure and server-side request issues. Their eligibility depends on the specific program and the demonstrated impact.
A behavior is not automatically a valid vulnerability because it appears unusual or differs from expected behavior. The report should establish a security boundary failure, a meaningful impact or another issue recognized by the program.
Check whether the program excludes issues such as best-practice observations without demonstrated impact, unsupported software versions, theoretical vulnerabilities, self-XSS, clickjacking without meaningful impact, rate-limit concerns without a demonstrated security consequence or findings that are already publicly known.
These are examples, not universal exclusions. Use the actual program's eligibility rules as the source of truth.
7. Evaluate reward terms
A published reward range is not a guarantee that every submission will receive a payment. Eligibility, severity, reproducibility, duplicate status, report quality, program rules and the organization's assessment can affect the outcome.
Before beginning research, review the current reward ranges, eligible issue classes, severity criteria, exclusions, duplicate policy and any special reward conditions.
Do not assume that a vulnerability qualifies for the highest reward in a published range. The organization may determine severity based on realistic impact, affected assets, prerequisites, exploitability and the limits of the program.
A valid finding may be accepted without a monetary reward if the program's terms do not provide one for that issue or if a stated exclusion applies. Review the published terms rather than relying on expectations from other programs.
If the program offers rewards, check any payment eligibility, verification, tax or payment-provider requirements before relying on a potential payout.
8. Check duplicates and previously known issues
Programs may decline reports that describe an issue already reported, previously identified internally or otherwise excluded by their rules.
Search any program-provided known-issues list, announcements and relevant documentation before submitting a report. The absence of a public record does not prove that the issue is unknown to the organization.
When a possible duplicate is discovered, explain any meaningful difference in affected assets, root cause or impact rather than submitting multiple reports that describe the same underlying issue.
Duplicate decisions are generally made by the organization reviewing the finding. Do not attempt to obtain private reports or internal records to determine whether another researcher submitted the issue first.
9. Plan a focused research session
A clear research plan helps keep testing within scope and makes findings easier to reproduce. Start with the program's highest-priority assets and the vulnerability classes relevant to their functionality.
Use the following workflow before running tools or interacting with production systems:
- Identify the exact target and confirm that it is currently in scope.
- Read the program's restrictions, eligibility rules and reporting instructions.
- Determine whether the planned test technique is explicitly permitted.
- Choose a low-impact verification method and define a clear stopping point.
- Use only the accounts, data and test environments allowed by the program.
- Keep concise notes about the target, relevant rules, test conditions and observed behavior.
- Prepare a report containing enough evidence for independent verification without unnecessary sensitive data.
10. Handle sensitive information carefully
Security testing can expose personal information, credentials, tokens, confidential business data or information belonging to other users. Treat unexpected access to such material as a reason to limit further interaction, not as permission to investigate everything that is accessible.
Do not browse through unrelated records, download bulk datasets, reuse exposed credentials or share sensitive evidence with people who do not need it.
Capture only the minimum evidence necessary to demonstrate the issue. Redact unrelated personal information, authentication secrets and confidential values from screenshots, logs and report attachments.
If sensitive data is exposed unexpectedly, stop the affected test, preserve only the minimum permitted evidence and report the situation promptly using the program's designated process.
Follow the program's data-handling and confidentiality requirements, including any instructions about deleting local copies after they are no longer necessary.
11. Use automation within program limits
Automation can help identify potential issues, but its use must remain within the program's scope and rate limits. A tool being widely used by researchers does not make every scan or test safe or authorized.
Review scan intensity, concurrency, request volume, authentication behavior and the possibility of state-changing requests before starting an automated run.
Avoid high-volume scanning, uncontrolled crawling or testing patterns that could degrade service availability, trigger account lockouts or affect other users.
Where the program imposes limits, configure your tools to respect them. If the limits or permitted automation methods are unclear, obtain clarification before running the test.
Validate automated findings manually where permitted. A scanner alert alone may be insufficient to establish exploitability, impact or eligibility for a reward.
12. Report findings clearly
A useful report explains what is vulnerable, how the behavior can be reproduced, what security impact it creates and which in-scope asset is affected.
Include the affected URL or asset, relevant prerequisites, concise reproduction steps, expected and actual behavior, impact analysis and supporting evidence. Use a test account or sanitized data where possible.
Avoid overstating impact or presenting speculative consequences as confirmed results. Clearly distinguish what you directly observed from what you infer.
Do not include unnecessary personal data, complete credential sets, unrelated source code or large data dumps. Provide the minimum evidence needed for the organization to validate the finding.
Submit through the reporting channel specified by the program and follow any required template, attachment limits, severity taxonomy or disclosure conditions.
13. Understand report outcomes
After submission, an organization may review the report, request more information, attempt to reproduce the issue, assess its severity, determine whether it is a duplicate or out of scope, and decide on remediation.
Possible outcomes depend on the program and the platform's available workflow. A report may be accepted, require clarification, be marked as a duplicate, be considered out of scope or be declined for another reason.
Respond to reasonable requests for clarification through the designated reporting channel. Provide additional evidence only when it is necessary and permitted by the program rules.
An initial acknowledgement does not necessarily mean that a vulnerability has been validated or that a reward has been approved. Likewise, acceptance does not by itself establish a payment date unless the program's terms say so.
14. Collaborate without expanding authorization
Working with teammates can help with analysis and report quality, but collaboration does not expand the underlying authorization. Every participant must follow the same applicable scope, restrictions and confidentiality requirements.
Share only the research material teammates need for their role. Avoid distributing sensitive evidence, credentials or personal data unnecessarily.
Before conducting a joint test, confirm that the activity is permitted, that participants understand the program's rules and that any team-specific conditions are satisfied.
If a team session or collaboration feature has separate rules, follow those rules alongside the program's requirements. Do not assume that joining a session grants authorization to test a target.
15. Monitor program changes
Program scope, restrictions, eligible vulnerability classes, reward terms and disclosure requirements may change over time. Re-check the current program details before starting a new session and whenever a relevant update is announced.
If authorization is withdrawn, an asset is removed from scope or the applicable rules become unclear, stop the affected testing activity until the situation is resolved.
Do not assume that an asset remains authorized because it was included when you first discovered it. The current applicable authorization and any communicated transition instructions determine whether testing may continue.
Keep a concise record of the program instructions and scope that applied when you conducted testing and submitted the finding. Do not retain unnecessary sensitive data merely to document authorization.
16. When instructions conflict
If the program description, asset listing, Rules of Engagement or direct instructions appear inconsistent, do not resolve the conflict by choosing whichever interpretation permits more testing.
Pause the activity affected by the conflict and request clarification from the program's designated contact. Include the relevant asset and the conflicting instructions without exposing unnecessary secrets or personal data.
Resume only when you have a sufficiently clear basis to understand the permitted target and technique. Keep the clarification with your research notes where appropriate.
17. Common mistakes to avoid
- Testing a related domain or third-party service that is not explicitly in scope.
- Assuming that public accessibility or technical ownership proves authorization.
- Ignoring asset-specific exclusions or restrictions on particular techniques.
- Running automated scans without checking rate limits or availability risks.
- Continuing to test after authorization has been withdrawn or become unclear.
- Accessing unrelated personal data or collecting more evidence than necessary.
- Submitting a scanner result without confirming the security impact.
- Assuming that a valid report guarantees a reward or a particular severity.
- Disclosing a vulnerability publicly before the applicable rules permit it.
- Relying on outdated program details instead of checking current instructions.
18. Researcher checklist
- I have read the complete program description and current Rules of Engagement.
- I have verified the exact asset and confirmed that it is in scope.
- I have checked exclusions, third-party boundaries and asset-specific conditions.
- My planned techniques, automation and request volume comply with program restrictions.
- I understand the eligible vulnerability classes, reporting requirements and reward terms.
- I will minimize impact and avoid unnecessary access to sensitive information.
- I know how to report a finding or unexpected security incident.
- I will stop and request clarification if authorization becomes unclear.
- I will submit a reproducible, accurate report with only the evidence needed for review.
19. Related guidance
Review the Getting Started guide for the overall research workflow, Account Security for protecting your Proofsec account, and the applicable organization or program rules for the exact target you intend to test.
The program's current scope and Rules of Engagement take precedence over general examples in this guide. If a specific instruction is unclear, request clarification before proceeding.