Getting started with Proofsec
Proofsec is a platform intended to help security researchers and organizations coordinate security research, communicate about vulnerabilities and manage the research process. The features available to you depend on the current platform implementation and your account permissions.
If you are new to Proofsec, start with the Getting Started guide, review the Rules of Engagement and learn how programs define eligible targets, testing conditions and disclosure requirements before beginning research.
Keep your account information accurate, secure your sign-in credentials and review the documentation whenever a workflow or platform policy changes.
- Read the Getting Started guide to understand the basic workflow.
- Review the Rules of Engagement before testing.
- Read the individual program requirements before participating.
- Use the account security guidance to protect your credentials and research material.
Does having a Proofsec account authorize me to test a website?
No. Creating an account or joining Proofsec does not grant permission to test arbitrary websites, applications, infrastructure or accounts. You may test only assets and techniques explicitly authorized by an applicable program or other valid authorization.
Authorization is limited by the program's published scope, exclusions, testing conditions, dates and other requirements. A target that belongs to the same company, uses a similar domain or is linked from an eligible asset is not automatically in scope.
If a program does not clearly authorize a particular action, do not assume that it is permitted. Ask the program owner for clarification before proceeding.
What is a security program?
A security program describes the assets an organization authorizes researchers to assess, the vulnerability classes it considers eligible, the testing restrictions that apply and the process for submitting findings.
Depending on the program, the description may also specify reward eligibility, severity criteria, duplicate handling, communication channels, disclosure expectations and other participation requirements.
Read the full program description rather than relying only on its title, summary or advertised maximum reward. The detailed rules determine what research is permitted and how findings are evaluated.
What does scope mean?
Scope defines the assets and testing activities covered by a program's authorization. It may identify eligible domains, subdomains, applications, APIs, IP ranges, repositories or other specific assets.
Out-of-scope assets and prohibited techniques remain excluded even when they appear related to an organization or an in-scope target. Scope can also include restrictions on automation, account creation, social engineering, denial-of-service testing or access to real user data.
Verify the exact hostname, application, environment and permitted technique before testing. If scope changes or authorization expires, follow the current program terms rather than relying on an older copy.
What if I am unsure whether an asset is in scope?
Do not test the uncertain asset until the program owner confirms that it is included. Similar branding, DNS relationships, shared infrastructure, certificates or links from an in-scope asset do not automatically make another asset eligible.
Describe the asset and explain why its eligibility is unclear using the program's designated communication channel. Avoid probing the asset merely to establish whether it belongs to the organization.
Keep a record of the scope information and clarification that you relied on. If the program does not provide a clear answer, limit your activity to assets whose authorization is unambiguous.
How should I begin security research?
Start by selecting a program whose scope, requirements and testing conditions you understand. Identify eligible assets, read the exclusions and confirm any prerequisites before performing security tests.
Build a testing plan around the program's permitted activities. Use controlled test accounts and non-destructive techniques wherever possible, and avoid unnecessary access to sensitive information.
Record the relevant requests, responses, affected components and reproduction steps as you work. Keeping concise notes makes it easier to verify a finding and prepare a clear report later.
- Choose an applicable program and read its complete requirements.
- Confirm the target and testing technique are authorized.
- Prepare a controlled test environment where practical.
- Document relevant observations and reproduction steps.
- Stop if further testing would exceed authorization or unnecessarily expose sensitive data.
What makes a good vulnerability report?
A useful report explains what is affected, what security property is violated, how the issue can be reproduced and what impact an attacker could realistically achieve. It should enable the receiving organization to understand, validate and address the problem.
Include the affected asset, prerequisites, a concise sequence of reproduction steps, relevant sanitized requests or responses, observed results and expected behavior. Explain the impact with evidence rather than unsupported severity claims.
Remove passwords, session cookies, API keys, private keys, personal information and unrelated customer data. Include only the evidence necessary to establish the issue, and make sure the reproduction steps remain understandable after redaction.
For more detailed guidance, read the Writing a Good Security Report documentation.
- Use a specific, descriptive title.
- Identify the affected in-scope asset.
- Provide clear, repeatable reproduction steps.
- Explain the security impact and supporting evidence.
- Redact secrets and unrelated sensitive information.
- Avoid speculative claims and unnecessary proof-of-concept complexity.
What happens after I submit a report?
A submitted report may need to be reviewed, reproduced, classified and assessed against the program's requirements. The organization may request clarification or additional safe evidence before making a decision.
A submission is not automatically accepted as valid, assigned a particular severity or approved for a reward. The outcome depends on the evidence, the program rules, the affected asset and the organization's review process.
Monitor the communication channel associated with your submission, respond to reasonable requests for clarification and keep any additional testing within the original authorization.
The exact report statuses, review timelines and notification mechanisms depend on the features and procedures implemented for the applicable program.
What report outcomes are possible?
A program may classify a report as valid, informative, out of scope, a duplicate, not applicable or another status defined by its workflow. The precise status names and meanings depend on the program and platform implementation.
A report can describe a real technical issue without meeting a program's eligibility requirements. For example, the affected asset may be excluded, the issue may be known already or the report may not demonstrate a meaningful security impact.
If a report is rejected or its classification is unclear, review the stated reason and the program's rules. Where the process permits, provide concise additional evidence or ask for clarification without repeating disruptive tests.
What is a duplicate report?
A duplicate report generally describes a vulnerability that has already been reported or identified. Programs may treat multiple reports of the same underlying issue differently from reports of separate vulnerabilities affecting the same application.
Two reports are not necessarily duplicates merely because they involve the same endpoint or vulnerability category. The relevant question is whether they describe the same underlying security issue under the program's duplicate policy.
Provide a clear explanation of the affected component, root cause and impact. Do not assume that a report is eligible for a reward solely because you independently discovered the issue.
Does every valid report receive a reward?
No. A valid security finding does not automatically guarantee payment. Rewards depend on the program's published terms, eligibility requirements, demonstrated impact, duplicate status, applicable exclusions and the organization's decision.
Some programs may accept findings without offering monetary rewards. Others may define reward ranges, severity-based amounts, eligibility restrictions or additional conditions that must be satisfied before payment.
Review the current program terms before beginning research. If the reward conditions are ambiguous, obtain clarification through the available program contact channel instead of relying on an advertised maximum amount.
How are severity and impact evaluated?
Severity generally reflects the practical security consequences of a vulnerability, including the affected assets, attacker capabilities, required prerequisites and potential impact on confidentiality, integrity or availability.
A report should explain the realistic consequences of the issue and provide evidence supporting its assessment. The presence of a particular bug pattern does not by itself establish a critical severity rating.
The organization or program may apply its own severity framework and eligibility rules. Researchers should describe the evidence accurately and avoid exaggerating impact to influence triage or reward decisions.
When and how are rewards paid?
Payment eligibility, amounts, methods, processing times, minimum thresholds, required verification and other conditions depend on the applicable program and the Rewards and Payments policy.
A report being submitted or accepted does not necessarily mean payment has been approved or processed. Review the program's payment conditions and any instructions provided after the finding is evaluated.
If a required payment detail is not published, ask the organization or Proofsec through the available official contact channel before relying on an assumption. Never send payment credentials or sensitive financial information through an unverified message.
Proofsec documentation should not be interpreted as a guarantee of a particular reward, payment date or tax outcome unless the applicable terms expressly provide it.
What about taxes and payment eligibility?
Tax obligations and reporting requirements depend on your jurisdiction, tax status, the nature of the payment and other individual circumstances. A program's reward description does not determine your personal tax treatment.
Check the applicable payment terms to understand eligibility, identity verification and required documentation. Provide sensitive information only through a verified process that is actually required for the payment.
For advice about your own tax obligations, consult a qualified tax professional or the relevant tax authority. Do not assume that a reward is tax-free or that the platform handles every reporting obligation on your behalf.
Can I work with other researchers?
You may collaborate using research sessions and other collaboration features that are available to your account and permitted by the applicable program.
Before work begins, agree on responsibilities, testing boundaries, evidence ownership, communication and any proposed reward split. Confirm that each participant is permitted to access the relevant program and shared material.
Collaboration does not expand the program's authorization. Every participant must follow the same scope restrictions and applicable rules, and team members should not share credentials or confidential material beyond what is necessary and permitted.
Available collaboration features and permissions depend on the platform implementation. Do not assume that every program supports team submissions, private chat, shared file storage or automatic reward distribution.
How should a team handle reward splits?
If a program allows collaborative submissions, agree on the intended reward split before research begins and document the agreement clearly. Discuss who will submit the report, who contributed to the finding and how the team will handle follow-up questions.
A private agreement between researchers does not override the program's eligibility rules or guarantee that the organization or platform will distribute a reward according to that agreement.
Confirm the applicable program's process for team findings and payments before depending on automated split functionality. If the process is not documented, ask the responsible organization or Proofsec contact for clarification.
Can I share code, files or evidence with my team?
Share only material that you are authorized to disclose and that your collaborators need to perform their roles. Verify the recipients and destination before sending code, screenshots, logs or other artifacts.
Remove credentials, session cookies, API keys, personal information and unrelated customer data. Avoid sharing full database dumps or broad collections of records when a minimal sanitized example is sufficient.
Keep track of important evidence versions and communicate before changing or deleting material that another researcher needs to reproduce the finding.
The availability and access controls of file-sharing features depend on the platform implementation. Do not assume that removing a message or leaving a session deletes copies that other participants have already downloaded.
Can I publish a finding after submitting it?
Follow the program's confidentiality requirements, coordinated-disclosure process and any applicable publication restrictions. Submitting a report does not automatically authorize public disclosure.
Do not publish exploit details, sensitive evidence, affected user information or other confidential material before the permission required by the program has been obtained and applicable disclosure conditions have been satisfied.
If you want to publish a technical write-up, clarify the permitted publication date, redaction requirements, attribution and any restrictions on proof-of-concept material with the relevant program owner.
Where the program has no clear disclosure policy, request clarification rather than assuming that a particular waiting period or publication rule applies.
What is responsible disclosure?
Responsible disclosure is a process for reporting security vulnerabilities privately to the appropriate party, allowing the issue to be assessed and addressed before details are made public under an agreed or applicable disclosure process.
A responsible report provides enough information to understand and reproduce the issue without unnecessarily exposing user data, disrupting services or expanding access beyond what is authorized.
Follow the program's stated communication and disclosure rules. If reporting a vulnerability in Proofsec itself, use the platform's published Responsible Disclosure instructions rather than submitting the issue to an unrelated program.
How do I report a vulnerability in Proofsec itself?
Use the Responsible Disclosure page linked from the documentation index and follow the instructions published there. Include a concise description of the affected component, potential impact, prerequisites and safe reproduction steps.
Avoid accessing, modifying, downloading or retaining other users' data. Use the minimum evidence needed to establish the issue and redact credentials or other sensitive information from attachments.
Keep the report private while it is being handled. Do not assume that a submission has been received, accepted or resolved until you receive confirmation through an appropriate channel.
If the published page does not specify a response timeline or disclosure process, do not invent one. Ask through the available official contact channel if clarification is necessary.
How does Proofsec reputation work?
Reputation systems can help communicate a researcher's history or contribution quality, but their meaning depends on the platform's actual scoring rules and displayed metrics.
A useful contribution generally benefits from accurate reproduction steps, clear evidence, realistic impact assessment, respectful communication and compliance with program requirements. Avoid duplicate submissions, unsupported severity claims and unnecessary disclosure of sensitive information.
Do not assume that every accepted report changes reputation by a fixed amount or that a particular score guarantees access to programs, rewards or privileges unless those rules are explicitly documented.
For the meaning of report outcomes and reputation indicators, consult the Reputation and Report Outcomes guide and any published rules associated with the feature.
What personal information does Proofsec collect?
The personal information processed by Proofsec depends on the features you use, your interactions with the platform and the applicable privacy practices. Information may be needed to operate an account, support research workflows, communicate about submissions or maintain platform security.
The Privacy Policy should identify the categories of information processed, the purposes and legal bases where applicable, retention practices, relevant recipients and the ways users can exercise their rights.
Do not assume that a particular data category is collected, shared or retained for a specific period unless the current Privacy Policy says so. Review the published policy for the authoritative explanation.
How can I protect my Proofsec account?
Use a unique password, secure the email account associated with Proofsec, keep your device and browser updated, and never share passwords, session cookies or authentication tokens.
Enable multi-factor authentication and use session-revocation or account-activity controls if those features are available. Verify suspicious sign-in requests and be cautious of messages that ask for urgent credential disclosure.
If you suspect compromise, change affected credentials from a trusted device, revoke active sessions where possible, secure your email account and report the incident through an official channel.
Read the Account Security guide for detailed advice on protecting credentials, research artifacts and collaborative sessions.
What should I do if I discover exposed credentials or personal data?
Stop once you have enough evidence to establish the exposure. Do not use exposed credentials to access additional systems or accounts, and do not download or retain more personal data than is necessary and explicitly permitted.
Record the minimum relevant details, such as the affected in-scope asset, the observation time and a sanitized description of the exposure. Avoid including live secrets in screenshots, reports or team chat.
Report the issue through the applicable program's designated channel. If the exposed information appears to affect a system outside the program's scope, do not continue testing that system without authorization.
What should I do if my report is rejected?
Read the decision and its explanation carefully. The issue may be out of scope, previously known, insufficiently reproducible, excluded by program rules or considered to have no qualifying security impact.
If you believe important evidence was overlooked, respond through the available report communication process with concise, relevant information that addresses the stated reason. Avoid resubmitting the same material repeatedly without new evidence.
Respect the program's review and appeal process where one exists. Do not assume that every decision can be appealed or that a particular review deadline applies unless the program documents it.
What should I do if a program's terms conflict with the documentation?
Review the current program-specific terms, the Rules of Engagement and the relevant platform policies. If requirements appear inconsistent, do not choose the more permissive interpretation automatically.
Pause the affected activity and ask the program owner or an appropriate Proofsec contact for clarification. Keep the response so that you can refer to the guidance that was provided.
Do not proceed with a disputed action until you have a clear basis for believing it is authorized. The applicable program may impose additional restrictions that are not covered by a general guide.
Where can I find exact payment or tax details?
Review the current program terms and the Rewards and Payments policy for reward eligibility, payment conditions and any published processing information.
If a required payment detail is not published, ask the organization or Proofsec through the available verified contact channel before relying on an assumption.
Tax obligations depend on your individual circumstances and jurisdiction. Consult the relevant tax authority or a qualified tax professional for advice specific to your situation.
Why can I not access a feature or page?
A feature may be unavailable because it has not been implemented, requires a particular account role, is limited to a specific program or is temporarily experiencing a technical issue.
Check that you are signed in to the intended account, that you have the required permissions and that the URL is correct. If the feature belongs to a particular program, confirm that your account is eligible to access it.
If the issue persists, record the page URL, the approximate time, the action you attempted and any visible error message. Do not include passwords, session cookies, access tokens or other secrets in a support request.
- Verify the URL and account you are using.
- Check the feature's documented prerequisites and permissions.
- Refresh the page or retry after confirming your connection.
- Record the error message and relevant non-sensitive details.
- Contact an official support channel if the problem persists.
How can I contact Proofsec?
Use the contact details or reporting channels published on the official Proofsec website and the relevant program page. Choose the channel appropriate to the issue, such as account access, a program question, a report dispute or a suspected platform vulnerability.
Include enough information for the recipient to understand the request, but do not send passwords, authentication tokens, recovery codes or unnecessary personal information.
For security vulnerabilities in Proofsec, follow the Responsible Disclosure instructions. Do not assume that an email address, response time or support service exists unless it is actually published by the platform.
Which documents should I read next?
The documentation library contains guides and policies covering different parts of the Proofsec workflow. The most relevant document depends on what you are trying to do.
- Getting Started — learn the basic account and research workflow.
- Platform Overview — understand the platform's main areas and how the workflow fits together.
- Programs and Scope — review program requirements and determine which targets and techniques are authorized.
- Writing a Good Security Report — prepare clear, reproducible findings.
- Research Sessions and Team Collaboration — coordinate research and handle shared material.
- Reputation and Report Outcomes — understand report decisions and documented reputation indicators.
- Account Security — protect your credentials, devices and research material.
- Organization Onboarding — learn how organizations prepare programs and review submissions.
- Rules of Engagement — understand testing restrictions and responsible research expectations.
- Privacy Policy — review the published privacy practices.
- Rewards and Payments — review the terms governing reward eligibility and payments.
- Responsible Disclosure — report vulnerabilities in Proofsec through the published process.