Proofsec - Security Research & Bug Bounty Platform

Welcome to Proofsec

Proofsec is designed to bring security researchers and organizations together around structured security research. Depending on the features available to your account, the platform can help you discover programs, understand their requirements, coordinate research, submit findings and follow report outcomes.

This guide walks you through the typical researcher workflow, from setting up your account to submitting a vulnerability report. Individual programs may impose additional requirements, and available platform features may vary.

Before beginning any research, familiarize yourself with the Rules of Engagement, the program's scope and the applicable disclosure requirements. Your Proofsec account alone does not authorize you to test any system.

Create and secure your account.
Complete your profile and review its visibility settings.
Choose a program whose scope and requirements you understand.
Plan and conduct authorized research.
Submit a clear, reproducible report.
Follow the review process and applicable reward terms.

Create your account and profile

Register using the official Proofsec website and provide the information required by the sign-up process. Choose a username that identifies you professionally and does not expose personal information you do not want to share publicly.

Verify your email address if verification is required. Keep the associated email account secure because it may be used for account notifications, recovery or other account-related communication.

Review your profile after registration. Depending on the features available, your profile may contain your username, biography, research interests, links, statistics, achievements or reputation information. Keep public information accurate and avoid including private contact details, credentials or other sensitive information.

Check the profile visibility and privacy controls available in your account settings. Do not assume that every profile field is private by default or that hiding a profile removes information already displayed elsewhere.

Use a unique password and enable multi-factor authentication if the feature is available. Never share your password, session cookies, recovery codes or authentication tokens with other users.

Register through the official Proofsec website.
Complete any required email verification.
Choose a username that does not reveal unnecessary personal information.
Review the information displayed on your profile.
Check profile visibility and privacy settings.
Secure your credentials and recovery methods.

Understand your dashboard

The dashboard is the starting point for navigating the parts of Proofsec available to your account. Depending on the current implementation, it may provide access to programs, research sessions, submitted findings, account information, notifications or reputation statistics.

Use the relevant section for the task you want to perform. Review program details before starting research, keep track of your report status after submission and check account settings when you need to manage your profile or security preferences.

A dashboard card, statistic or notification should not be treated as a substitute for the full program terms or an official report decision. Open the relevant record to review the details before acting on the information.

Use the program area to discover eligible research opportunities.
Use the available session features to organize collaborative work.
Review submitted findings and their status through the supported report workflow.
Manage profile and account preferences through the available settings.
Consult the documentation when a feature or status is unclear.

Pick a program

Browse the available security programs and compare their scope, requirements and objectives. Choose a program that matches your technical skills, available time and understanding of the permitted testing methods.

A program description may include eligible assets, excluded assets, vulnerability categories, testing restrictions, disclosure rules, reward eligibility and other conditions. Read the full description rather than relying only on the title, summary or advertised maximum reward.

Programs may focus on different technologies or environments, such as web applications, mobile applications, APIs, cloud services or other explicitly listed assets. The availability of these categories depends on the programs published on Proofsec.

Only assets and techniques covered by valid authorization are eligible for testing. A related domain, shared IP address, linked service or asset owned by the same organization is not automatically in scope.

Check whether the program is active and whether its authorization, exclusions or requirements have changed. If the scope is unclear, ask the program owner for clarification before interacting with the uncertain asset.

Read the program description and eligibility requirements.
Identify the exact in-scope assets and permitted testing methods.
Review exclusions, prohibited activities and rate limits.
Understand the reporting and disclosure process.
Check reward conditions and duplicate-report rules.
Confirm that the program is active and that you are eligible to participate.

Understand scope and testing restrictions

Scope defines the systems and activities covered by a program's authorization. It may identify exact domains, subdomains, application URLs, API endpoints, repositories, IP ranges or other assets.

Do not infer authorization from branding, DNS records, certificates, redirects or technical relationships between systems. If an asset is not explicitly included or otherwise clearly authorized, treat its eligibility as unconfirmed.

Review restrictions on automation, account creation, destructive testing, denial-of-service activity, social engineering, physical access, third-party services and handling sensitive data. Restrictions differ between programs.

Use the least intrusive testing method that can establish the vulnerability. Avoid disrupting availability, modifying real user data or accessing information beyond what is necessary to demonstrate the issue.

If a test unexpectedly exposes sensitive information or reaches a system outside the authorized scope, stop the relevant activity, preserve only the minimum necessary evidence and follow the program's reporting instructions.

Verify the exact target before testing.
Follow all program-specific exclusions and restrictions.
Do not test third-party systems without authorization.
Avoid unnecessary data access or service disruption.
Request clarification when authorization is ambiguous.

Plan your research

Before testing, define the asset you will assess, the security property you want to examine and the methods permitted by the program. A short plan helps keep research focused and makes it easier to explain your findings later.

Use controlled test accounts and synthetic data where practical. Record relevant observations, request details, response behavior and environmental assumptions as you work.

Separate confirmed behavior from hypotheses. A suspicious response or unusual application behavior is a starting point for investigation, not necessarily proof of a vulnerability.

Keep research artifacts organized and protect them from accidental disclosure. Redact secrets and personal information from notes, screenshots, logs and code snippets before sharing them.

Set a clear stopping point. Once you have sufficient evidence to establish the issue, avoid further access or exploitation that would increase risk without materially improving the report.

Define the authorized asset and objective.
Choose testing methods permitted by the program.
Prepare controlled accounts and test data where practical.
Record reproducible observations.
Protect evidence and redact sensitive information.
Stop once sufficient evidence has been collected.

Research solo or as a squad

You may conduct research independently or collaborate with other researchers using the session and team features available to your account. Collaboration can help distribute tasks, review evidence and reproduce findings, but it does not expand the program's authorization.

Before starting a shared session, agree on responsibilities, testing boundaries, communication and evidence ownership. If the program permits shared submissions or reward splitting, agree on the intended arrangement before work begins and verify the applicable rules.

Invite only intended participants and share material only with people who are permitted to access it. Do not place passwords, session cookies, API keys, private keys or unnecessary customer data in shared chat or files.

Keep notes and code snippets clearly labeled, and communicate when you change a testing assumption or discover information that affects another teammate's work.

The number of supported team members, invitation mechanisms, chat features, file-sharing capabilities and reward-splitting options depend on the actual platform implementation. Use only the features available in your session.

Choose solo or collaborative research according to the task.
Invite teammates through the supported workflow.
Agree on roles and any permitted reward split in advance.
Keep shared notes and evidence organized.
Share only authorized material with intended recipients.
Verify that every participant follows the same program restrictions.

Identify and validate a potential vulnerability

A potential vulnerability is a behavior that may violate a security boundary, expose protected information, allow unauthorized actions or otherwise compromise a system's intended security properties.

Validate the observation using a repeatable, non-destructive method permitted by the program. Identify the relevant prerequisites and distinguish the behavior you observed from the impact you believe it could have.

Use the minimum proof necessary to establish the issue. Do not access unrelated accounts, collect large amounts of private information, persist access or perform destructive actions to make a report appear more severe.

Check whether the issue is already documented in the program's known exclusions or duplicate guidance. Do not assume that a similar-looking issue is a duplicate without considering its root cause and security impact.

If the result cannot be reproduced, document the conditions under which it occurred and the uncertainty that remains. Do not present an unverified hypothesis as a confirmed vulnerability.

Reproduce the behavior using an authorized method.
Identify the affected security boundary or property.
Determine the minimum evidence needed to demonstrate the issue.
Assess realistic impact without exaggeration.
Avoid unnecessary access, disruption or data collection.

Write a finding that can be reviewed

A good vulnerability report is concise, reproducible and accurate about impact. Its purpose is to help the receiving organization understand the problem, verify it safely and identify an appropriate remediation.

Use a descriptive title that identifies the issue and affected component. Name the exact in-scope asset and provide any relevant prerequisites, such as account role, configuration or user interaction.

Describe the behavior you observed, the expected behavior and the security consequence. Separate demonstrated impact from possible consequences that have not been verified.

Write numbered reproduction steps that another person can follow without guessing. Include sanitized requests, responses, screenshots or code snippets only when they add meaningful evidence.

Remove passwords, tokens, private keys, personal information and unrelated customer data. Do not include large data dumps or sensitive artifacts when a small redacted example is sufficient.

For additional examples and a suggested report structure, consult the Writing a Good Security Report guide.

Title: identify the vulnerability and affected component.
Affected target: specify the exact in-scope asset.
Summary: explain the issue in a few clear sentences.
Prerequisites: describe required access, configuration or user interaction.
Steps to reproduce: provide numbered, repeatable instructions.
Evidence: include the minimum sanitized proof needed for verification.
Impact: explain realistic security consequences.
Remediation guidance: suggest a practical fix when you can do so confidently.

Submit your report

Submit the finding through the reporting workflow provided by the applicable Proofsec program. Before submission, verify that the target is in scope, the report follows the program's requirements and the evidence does not disclose unnecessary sensitive information.

Review the report for clarity and completeness. Make sure the reproduction steps match the evidence, the affected asset is identified correctly and the impact statement reflects what you actually demonstrated.

Avoid submitting the same finding multiple times through different channels unless the program explicitly instructs you to do so. If the submission interface fails, check whether the report was created before retrying, where the platform provides a way to verify submission status.

Keep a copy of the report reference or confirmation when available. Do not assume that a report has been received, accepted or approved for a reward merely because you prepared the submission.

Check the program's submission instructions.
Confirm the target and issue are eligible.
Remove secrets and unnecessary personal information.
Verify that the report and evidence agree.
Submit through the designated reporting channel.
Retain the submission reference or confirmation if provided.

What happens after submission?

After submission, the organization may review the report, attempt to reproduce the issue, assess severity and determine whether the finding meets the program's requirements. The review may involve follow-up questions or requests for additional safe evidence.

Respond clearly to requests for clarification and provide only information relevant to the finding. Do not perform additional testing outside the original authorization simply because a reviewer asks for more information; request clarification if the requested action is not clearly permitted.

A report's status and available next steps depend on the program and the platform's implemented workflow. Review the recorded decision and any explanation provided rather than assuming that every program uses identical status names or review timelines.

If you disagree with a decision, read the stated reason and the program's review policy. Where an appeal or clarification process exists, use it to provide specific evidence that addresses the decision.

Monitor the available report status and communications.
Respond to relevant questions with concise evidence.
Keep follow-up testing within the authorized scope.
Review the decision and stated reason.
Use the documented clarification or appeal process where available.

Understand report outcomes

Programs may classify findings as accepted, duplicate, informative, out of scope, rejected or another status defined by their workflow. Exact names and meanings vary, so consult the program's definitions and the explanation associated with your report.

An accepted report generally means that the finding has met the relevant acceptance criteria. It does not necessarily mean that a payment has already been approved or processed.

A duplicate outcome may mean that the same underlying issue was already reported. An informative or rejected outcome may indicate that the submission did not meet the program's criteria, lacked sufficient evidence or did not demonstrate an eligible security impact.

If the reason is unclear, ask for clarification through the supported communication process. Avoid repeatedly resubmitting unchanged reports without new evidence.

Rewards and payments

Reward eligibility depends on the program's published terms, the report's outcome, severity criteria, duplicate status and any additional conditions. Some programs may not offer monetary rewards.

A published reward range or maximum amount is not a guarantee that a particular finding will receive that amount. The actual decision depends on the program's rules and assessment of the demonstrated impact.

Payment methods, processing timelines, minimum thresholds, eligibility restrictions, verification requirements and tax documentation depend on the applicable program and payment policy.

If you are collaborating with other researchers, verify whether the program supports team rewards or split payments. A private agreement between researchers does not automatically guarantee that the organization or platform will distribute payment according to that agreement.

Read the Rewards and Payments documentation and the individual program terms before beginning research. For personal tax questions, consult the relevant tax authority or a qualified tax professional.

Build a strong research reputation

A professional research history is built through accurate reporting, reproducible evidence, realistic impact assessments, respectful communication and consistent compliance with program requirements.

Focus on the quality of your work rather than the number of submissions. A small number of well-supported findings is more useful than repeated low-quality reports, speculative claims or duplicate submissions.

Explain uncertainty honestly and correct mistakes when you discover them. Clear communication with program owners and reviewers helps them assess findings and reduces unnecessary back-and-forth.

Reputation scores, leaderboards, achievements and their effects depend on the rules and features actually implemented by Proofsec. Do not assume that a particular report outcome automatically changes a score by a fixed amount or guarantees access to additional opportunities.

Submit reproducible findings supported by evidence.
Describe realistic impact without exaggeration.
Respect scope, confidentiality and program requirements.
Respond professionally to reviewer feedback.
Review the Reputation and Report Outcomes guide for further details.

Protect your account and research material

Your account and research artifacts may provide access to sensitive program details, reports, private communications and collaborative work. Protecting them is part of conducting responsible security research.

Use a unique password, secure your associated email account and enable multi-factor authentication if available. Never share authentication tokens, session cookies or recovery codes with teammates or support contacts.

Redact secrets from screenshots, logs and code snippets. Keep private findings out of public repositories and file-sharing services unless disclosure is explicitly authorized.

Review session membership and file recipients before sharing material. If you suspect account compromise, change affected credentials from a trusted device, revoke sessions where possible and use an official contact channel to report the incident.

Read the Account Security guide for more detailed recommendations.

Use a unique password and protect recovery methods.
Keep devices and browsers updated.
Redact secrets and unnecessary personal information.
Check sharing permissions before uploading evidence.
Report suspected account compromise through an official channel.

Common mistakes to avoid

Testing assets that are not explicitly authorized.
Assuming that an organization's related domains are automatically in scope.
Ignoring program exclusions or restrictions on testing techniques.
Submitting reports without clear reproduction steps or evidence.
Exaggerating severity or describing speculative impact as confirmed.
Including passwords, tokens or personal information in reports.
Assuming every valid report receives a monetary reward.
Assuming that acceptance guarantees immediate payment.
Sharing confidential findings publicly before authorization.
Inviting collaborators who are not permitted to access the relevant material.
Repeating tests that could disrupt a service after sufficient evidence has been collected.
Assuming that a platform feature exists simply because it is mentioned in a general guide.

Your first-research checklist

Before starting your first research task, use this checklist to confirm that your account is prepared, the target is authorized and you understand how to submit a finding.

I have registered and completed any required account verification.
I have reviewed my profile visibility and account security settings.
I have selected an applicable program and read its full description.
I have identified the exact in-scope asset and permitted testing methods.
I understand the exclusions, disclosure requirements and reward conditions.
I have planned a non-destructive way to validate a potential issue.
I know how to record evidence without exposing secrets or personal information.
I can write clear, repeatable reproduction steps.
I know where to submit the report and how to review its outcome.
I understand that authorization and program rules take precedence over assumptions.

Where to go next

Once you understand the basic workflow, use the other documentation guides to learn more about the parts of Proofsec relevant to your research.

Platform Overview — understand the main platform areas and the research workflow.
Programs and Scope — learn how to assess authorization and program restrictions.
Writing a Good Security Report — prepare clear and reproducible vulnerability reports.
Research Sessions and Team Collaboration — coordinate research with other participants.
Reputation and Report Outcomes — understand report decisions and documented reputation indicators.
Account Security — protect your credentials, devices and research artifacts.
Frequently Asked Questions — find answers to common questions about programs, reports, collaboration and rewards.
Rules of Engagement — review the rules that govern permitted research and disclosure.
Rewards and Payments — review reward eligibility and payment conditions.