Rules of Engagement

1. Scope decides what is allowed

You may only test targets explicitly listed as in scope in an active program you are authorized to participate in. You must follow the program description, exclusions, testing restrictions and any additional instructions published by the organization.

A domain, IP address, application, API, mobile application or service is not automatically in scope because it belongs to the same organization, uses the same branding or shares infrastructure with an authorized target.

Anything not explicitly authorized must be treated as out of scope. This includes related subdomains, third-party services, employee accounts, production systems and infrastructure unless the program clearly includes them.

If the scope is incomplete, ambiguous, inconsistent or appears outdated, stop the relevant testing and request clarification through the program's designated contact before proceeding.

Authorization applies only while the program and the relevant asset remain eligible for testing. Respect scope changes, exclusions, suspension notices and program closure instructions.

2. Read the program requirements before testing

Before beginning research, review the program description, in-scope assets, excluded assets, prohibited techniques, eligibility requirements, reporting instructions and any published reward conditions.

Program-specific restrictions may be stricter than these general rules. You must follow both the general Rules of Engagement and the applicable program requirements.

If two instructions appear to conflict, do not assume that the more permissive interpretation applies. Pause the affected activity and ask the organization for clarification.

Keep a record of the program version, relevant scope information and material changes that affect your authorization. Do not rely on an old scope list or a previous authorization after the organization has changed its requirements.

3. Do no harm

• Do not perform denial-of-service attacks, stress tests, load tests, resource exhaustion or other activities that could impair availability or reliability.
• Do not delete, modify, corrupt or encrypt data belonging to an organization or another person.
• Do not access, change or interfere with another user's account beyond the minimum necessary to verify an explicitly authorized finding.
• Do not conduct phishing, social engineering, impersonation, credential harvesting or physical attacks unless a program explicitly authorizes a specific activity and defines its limits.
• Do not send spam, unsolicited bulk messages or excessive requests that could affect a service or its users.
• Do not install persistence mechanisms, backdoors, malware or unauthorized agents, and do not attempt to maintain access after the necessary proof has been collected.
• Do not pivot into unrelated systems, escalate access beyond what is needed to establish impact or use a vulnerable component as a stepping stone to unauthorized targets.
• Use your own test accounts and test data wherever possible and permitted by the program.
• Stop immediately if your testing causes unexpected disruption, exposes sensitive information or risks affecting real users.

4. Testing techniques and automation

Use testing techniques that are proportionate to the suspected vulnerability and permitted by the program. Prefer the least intrusive method that can establish whether a security issue exists.

Automated scanners and scripts may be used only when permitted by the program. Configure them to avoid excessive request rates, destructive checks and unrelated assets.

Do not assume that a publicly accessible endpoint, an exposed service or a successful connection grants permission to test it.

Do not bypass program restrictions by rotating IP addresses, distributing requests across accounts, changing user agents or delegating prohibited activity to other people or services.

Do not use compromised infrastructure, stolen credentials, unauthorized proxies or another person's account to conduct research.

Automated findings must be reviewed and validated. Scanner output alone does not establish exploitability, impact or eligibility for a report.

If a test unexpectedly triggers account lockouts, service degradation, security alerts or other operational effects, stop the test and report the situation to the appropriate program contact.

5. Protect accounts and credentials

• Use only accounts you own or accounts you have explicit permission to use for the specific test.
• Never use credentials obtained from unrelated breaches, leaks, public repositories or other unauthorized sources to access a target.
• Do not attempt credential stuffing, password spraying or brute-force attacks unless the program explicitly permits the exact technique and defines its limits.
• Do not change passwords, recovery settings, multi-factor authentication settings or account ownership for other users.
• Do not create large numbers of accounts to bypass program limits, abuse rewards or interfere with service operation.
• If you discover exposed credentials, do not use them to explore the account. Record only the minimum evidence needed and report the exposure privately.
• Protect your own Proofsec account, devices, research environment and session credentials against unauthorized access.

6. Handle personal and confidential data carefully

If you encounter personal information, confidential business data, authentication secrets or other sensitive material, stop the activity that exposed it and assess whether further access is necessary. In most cases, it is not.

Collect only the minimum evidence required to demonstrate the vulnerability. Prefer redacted screenshots, synthetic examples, limited metadata or a short description over copies of actual sensitive records.

Do not browse through exposed records, enumerate unrelated users, download databases, export files in bulk or access additional information merely to estimate the full extent of an issue.

Do not publish, sell, transfer, trade or otherwise disclose sensitive information discovered during research. Do not use it for personal gain or to gain leverage over an organization.

Store necessary evidence securely, restrict access to people who need it for the report and avoid placing secrets in public repositories, screenshots, shared notes or chat messages.

Remove unnecessary sensitive material from your working files as soon as possible. Delete collected material when it is no longer needed for the authorized report, subject to applicable legal obligations and any legitimate evidence-preservation requirements.

If you believe you have accessed a substantial amount of sensitive data or caused an unintended exposure, stop testing and notify the organization promptly through an appropriate private channel.

Do not assume that submitting a report automatically authorizes continued access to the affected system or continued retention of collected data.

7. Report privately and responsibly

Submit findings through the reporting channel specified by the active program. Include enough information for the organization to reproduce, assess and remediate the issue without unnecessary access to sensitive data.

Reports should describe the affected asset, prerequisites, reproduction steps, observed behavior, expected behavior, security impact and relevant supporting evidence.

Keep report details, proof-of-concept code, screenshots, affected records and remediation discussions private unless the organization has explicitly approved disclosure.

Do not publish vulnerability details, exploit code, internal communications or identifying information about affected users without the required authorization.

If a report remains unresolved, coordinated disclosure must follow the applicable program terms and any separately agreed disclosure timeline. There is no universal disclosure deadline under these general rules.

A disclosure deadline, where applicable, does not automatically grant permission to publish confidential information, expose personal data or disregard a program's terms or applicable law.

If the organization requests additional information, provide reasonable clarification where possible. Do not continue testing simply because the initial report has not received a response.

For vulnerabilities affecting Proofsec itself, use the designated responsible disclosure channel or contact contact@proofsec.net. Avoid publicly sharing exploitable details while the issue is being assessed.

If you are uncertain whether a proposed disclosure is authorized, keep the information private and request written clarification first.

8. Write accurate and useful reports

• Report only findings you have personally verified or can substantiate with reliable evidence.
• Clearly distinguish confirmed behavior from assumptions, hypotheses and unverified potential impact.
• Explain the security consequence rather than relying solely on scanner classifications or theoretical severity.
• Provide concise, reproducible steps and use test data wherever possible.
• Do not exaggerate impact, claim access you did not obtain or omit material facts that would change the assessment.
• Do not submit fabricated, copied, misleading or knowingly duplicate reports to inflate reputation or obtain rewards.
• If you discover that a report contains an error, notify the organization and correct the information promptly.
• Do not conceal harmful side effects or continue exploiting an issue after sufficient evidence has been obtained.

9. No extortion, coercion or unauthorized sale

Never demand payment outside the program in exchange for withholding a vulnerability, keeping information confidential or refraining from further exploitation.

Never threaten to publish a finding, expose customer data, disrupt a service or damage an organization's reputation to pressure it into paying a reward.

Do not sell, auction, license or transfer confidential vulnerability details or access obtained through unauthorized activity to unrelated parties.

A reward is governed by the applicable program terms. The discovery of a vulnerability does not give a researcher ownership of the affected system, its data or an automatic entitlement to payment.

Keep reward discussions within the designated process. Disputes about eligibility, severity or payment must not be used to justify further unauthorized access or disclosure.

10. Working in sessions and teams

Every participant is responsible for their own conduct, actions and contributions during collaborative research. Joining a session does not expand the scope of authorization.

Share only code, files, notes and evidence that you are permitted to disclose to the people in the session.

Never upload credentials, private keys, session tokens, personal information or confidential third-party data unless sharing that material is strictly necessary, authorized and handled through an appropriate secure process.

Invite only people you trust and who are permitted to participate in the relevant research. Do not use a team session to provide unauthorized access to a target or to evade program restrictions.

Do not impersonate another researcher, claim credit for another person's work without agreement or submit someone else's findings as your own.

Agree on responsibilities and contribution records before submitting a joint report. Follow the program's rules for collaboration, attribution and reward allocation.

Do not assume that all participants are authorized to view every piece of evidence. Limit access to what each participant needs.

If a participant violates these rules, stop contributing to the prohibited activity and notify the appropriate program contact or Proofsec support.

11. Authorization and safe harbor

An organization may authorize research on its assets through the scope and terms of its program. That authorization is limited to the assets, techniques, time period and conditions the organization has actually approved.

Where offered, safe harbor describes the organization's commitment concerning good-faith research conducted within the program's stated boundaries. Researchers must read the exact wording and conditions that apply to the program.

Safe harbor is not unlimited immunity and does not authorize testing beyond the program scope, activity prohibited by the Rules of Engagement or interference with third-party systems.

Proofsec does not own the targets merely because they are listed on the platform. Proofsec cannot grant authorization on behalf of an organization unless it has the authority to do so.

An organization's program terms cannot automatically bind independent third parties, service providers, authorities or other entities that have not granted the relevant permission.

Do not interpret silence, a delayed response, a previously accepted report or an earlier testing approval as permission to exceed the current scope.

If you are unsure whether an action is authorized, pause the affected test and obtain clarification from the organization before proceeding.

12. Respect program decisions and operational requests

Follow reasonable requests from the organization to pause testing, limit a technique, stop accessing an affected asset or provide clarification about your activity.

If a program is paused, an asset is removed from scope or authorization is withdrawn, stop testing the affected target as soon as practicable.

Do not continue exploitation while waiting for a report to be triaged, a reward decision to be made or a dispute to be resolved.

A request to stop testing does not prevent you from preserving a concise, securely stored record of activity already performed or from communicating privately about an existing report.

If you believe a request conflicts with the published program terms, raise the issue through the designated contact instead of independently expanding your testing.

13. Third-party services and infrastructure

A program's inclusion of an organization's website does not necessarily authorize testing its cloud provider, hosting infrastructure, identity provider, payment processor, content delivery network or other external services.

Do not test a third-party asset unless the program explicitly includes it or the relevant owner has separately authorized the activity.

When a vulnerability appears to originate in a third-party component, collect the minimum evidence needed to explain the suspected issue and report it to the program. Do not expand testing to unrelated customers or tenants.

Do not access neighboring accounts, cloud storage, containers, virtual machines or infrastructure belonging to other customers to demonstrate impact.

If ownership or authorization is unclear, treat the affected asset as out of scope until the appropriate party confirms otherwise.

14. Conflicts of interest and research integrity

• Disclose relevant conflicts of interest when required by the program or when they could materially affect the assessment of your research.
• Do not manipulate reports, evidence, timestamps, identities or collaboration records to influence triage, reputation or reward decisions.
• Do not coordinate duplicate submissions under multiple accounts to increase the chance of receiving credit.
• Do not interfere with another researcher's testing, accounts, report or communication with the organization.
• Do not use confidential information obtained through one program to target another organization without independent authorization.
• Correct material inaccuracies in your submissions when you become aware of them.

15. Platform use and account integrity

Use Proofsec to support legitimate, authorized security research and comply with the platform's applicable terms, privacy requirements and program-specific rules.

Do not create or use accounts to evade restrictions, impersonate others, manipulate reputation, fabricate participation or abuse program workflows.

Do not attempt to access another user's private messages, reports, files, account data or session material without authorization.

Do not exploit vulnerabilities in Proofsec to access data, alter records, interfere with services or obtain privileges beyond those assigned to your account.

Report security issues in Proofsec privately through the designated disclosure channel or by contacting the address listed in this document.

Keep your account credentials private and promptly report suspected unauthorized access or compromise.

16. Reporting an accidental violation or exposure

If you accidentally access out-of-scope data, trigger an unintended effect or exceed a testing boundary, stop the relevant activity immediately.

Do not attempt to conceal the incident by deleting logs, altering evidence or continuing the test to make the result appear intentional or harmless.

Record only the minimum facts needed to explain what happened, including the affected asset, approximate time, actions taken and any observed impact.

Notify the organization through an appropriate private channel as soon as reasonably possible. If the incident affects Proofsec, contact the designated disclosure channel or the address listed in this document.

Secure any evidence already collected and avoid further access. Follow reasonable instructions about containment, remediation and the handling of affected information.

Prompt, accurate reporting helps the affected party assess the incident, but does not guarantee that a violation will be excused or that a particular outcome will follow.

17. Consequences of breaking these rules

Violations may result in report rejection, removal from a program, loss of eligibility for a reward, restrictions on platform participation, suspension or permanent account termination.

Proofsec may review relevant reports, session activity and other available information to assess suspected violations, subject to applicable privacy requirements and platform procedures.

Where appropriate, Proofsec may notify the affected organization or share information reasonably necessary to investigate a suspected violation, respond to an incident or meet a legal obligation.

Serious incidents may also be referred to the relevant organization or other appropriate authority where warranted. Platform decisions do not replace any independent legal assessment.

The response may depend on the nature of the activity, its impact, whether it was deliberate or repeated, the researcher's cooperation and the applicable program terms.

A disagreement about a report, severity rating, reputation result or reward does not authorize retaliation, threats, continued exploitation or unauthorized disclosure.

If you believe a platform decision is incorrect, use the available review or support process and provide relevant, factual information.

18. Responsibilities of participating organizations

Organizations are responsible for defining clear program scope, identifying exclusions, describing permitted testing methods and communicating material restrictions.

Where an organization offers safe harbor, it should state the applicable conditions and the boundaries of its commitment clearly.

Organizations should provide an appropriate private reporting channel and identify any program-specific requirements for evidence, triage, rewards and disclosure.

Researchers should not assume that every organization uses the same eligibility criteria, response times, severity model or reward policy. The published program terms govern those details.

Proofsec's platform rules do not replace an organization's responsibility to provide accurate program information or to make decisions within its authority.

19. Changes to scope or rules

Programs and these Rules of Engagement may change over time. Review the current version before starting a new test and whenever you receive a material update.

If a scope change removes an asset or prohibits a previously permitted technique, stop the affected activity and follow the updated requirements.

Do not assume that a change retroactively authorizes activity that was outside scope when it occurred.

If a change materially affects an ongoing test or an existing report, ask the program contact how the updated terms apply before taking further action.

The version and effective date of applicable program terms may matter when resolving questions about authorization or compliance.

20. Researcher pre-test checklist

• I have reviewed the active program and its current rules.
• The target is explicitly in scope and the testing method is permitted.
• I understand the exclusions, third-party boundaries and stop conditions.
• My testing plan uses the least intrusive method that can verify the issue.
• Automation, request rates and account usage comply with program restrictions.
• I will stop if I encounter sensitive data, unexpected impact or unclear authorization.
• I will collect only the minimum evidence required and keep it private.
• My report will contain accurate, reproducible steps and a clear explanation of impact.
• I understand the applicable disclosure requirements and reward conditions.
• I know how to contact the organization or Proofsec if I need clarification.

21. Final principle

Security research must remain within explicit authorization, minimize risk to people and systems, protect confidential information and communicate findings responsibly.

When the next step is unclear, do not assume permission. Pause, preserve the minimum information needed and ask the organization for clarification before continuing.

For questions about these rules or security issues affecting Proofsec, contact contact@proofsec.net.