Bazinet Vault
← All posts
security

Security Research Policy for bazinet.net

Bazinet.net Bug Bounty Program

Bazinet.net welcomes good-faith security research that helps keep our users and systems safe.

All our of public source code can be found here:
https://github.com/BazinetDev/bazinet-vault-srcpublic

This is a small independent project, so our bug bounty program is intentionally simple and modest. If you find a real security vulnerability affecting bazinet.net or related first-party services, report it privately and we may offer a reward based on severity, impact, and report quality.

Contact

Please send reports to:

admin@bazinet.net

Suggested subject line:

[Security Report] bazinet.net - short issue title

Please include enough detail for us to safely reproduce the issue.

Scope

The following are generally in scope:

  • https://bazinet.net/*
  • Public marketing pages
  • Blog pages and content rendering
  • Account signup, login, reset, and verification flows
  • The Bazinet Vault web app
  • First-party API endpoints used by bazinet.net
  • Admin pages and account-management features owned and operated by Bazinet.net

Priority areas

We are especially interested in reports involving:

  • Authentication bypass
  • Account takeover
  • Privilege escalation
  • Broken access control or IDOR
  • Stored or reflected XSS
  • CSRF on sensitive actions
  • Session management issues
  • Password reset or 2FA bypass
  • Passkey or authentication flow weaknesses
  • Admin panel exposure or abuse
  • Security flaws with meaningful impact on user privacy, account safety, or vault access

Out of scope

The following are generally not eligible for bounty rewards unless there is a clear, demonstrated security impact:

  • Missing headers without exploitability
  • Clickjacking on non-sensitive pages
  • Open redirects without a realistic abuse path
  • Username or email enumeration with minimal impact
  • Version disclosure or technology fingerprinting alone
  • Best-practice recommendations without a specific vulnerability
  • Self-XSS that only affects your own browser session
  • Reports requiring browser console access by the victim
  • Social engineering, phishing, or physical attacks
  • Denial-of-service, spam, resource exhaustion, or destructive testing
  • Vulnerabilities only affecting third-party services not owned by Bazinet.net
  • Duplicate reports of already-known issues

Rules of engagement

To remain authorized under this policy, you must:

  • Act in good faith
  • Avoid accessing, changing, or retaining other users’ data beyond what is strictly necessary to demonstrate the issue
  • Use test accounts you control whenever possible
  • Stop testing and report immediately if you encounter real user data unintentionally
  • Avoid high-volume automated scanning that could degrade service
  • Avoid persistence, backdoors, spam, or any destructive action
  • Keep findings private until we have had a reasonable opportunity to investigate and fix the issue

Safe harbor

If you follow this policy, act in good faith, and avoid harmful or destructive behavior, Bazinet.net authorizes testing conducted within these guidelines.

This safe harbor does not apply to:

  • Intentional service disruption
  • Bulk data extraction
  • Data destruction
  • Public disclosure before remediation or approval
  • Extortion, threats, or any attempt to leverage a vulnerability beyond responsible reporting

Severity and reward ranges

Because this is an early-stage independent project, rewards are modest but intended to be fair.

| Severity | Reward range |
|---|---:|
| Critical | $750 - $1,500 |
| High | $250 - $600 |
| Medium | $75 - $200 |
| Low | $10 - $50 |
| Informational | $0 |

How we define severity

Critical

Issues that could lead to:

  • Full admin compromise
  • Complete authentication bypass
  • Severe multi-user data exposure
  • Major compromise of account security or vault access
  • Remote code execution or equivalent server-side impact

High

Issues that could lead to:

  • Account takeover of another user
  • Serious privilege escalation
  • High-impact stored XSS
  • Bypass of important authentication protections
  • Access to sensitive admin or internal functionality

Medium

Issues that could lead to:

  • Reflected XSS with realistic impact
  • CSRF on meaningful authenticated actions
  • Limited but real unauthorized access
  • Moderate business logic abuse
  • Narrow but valid access-control flaws

Low

Issues that could lead to:

  • Low-impact information disclosure
  • Minor misconfiguration with a realistic exploit path
  • Lower-risk security weakness with limited practical impact

Informational

Valid observations with little or no direct exploitability. These may be appreciated and tracked internally, but are usually not paid.

Final payout factors

Final reward amounts are discretionary and may depend on:

  • Real-world impact
  • Quality and clarity of the report
  • How easy the issue is to reproduce
  • Whether the finding is novel or already known
  • Whether the report includes a realistic proof of concept
  • Whether the issue affects authentication, admin access, billing, or user privacy

We may increase a reward for especially clear, helpful, and high-signal reports. We may reduce or decline a reward for overstated, incomplete, duplicate, or non-actionable submissions.

Example eligible reports

Examples of reports likely to qualify:

  • Taking over another user account
  • Bypassing password reset, verification, passkey, or 2FA protections
  • Accessing another user’s private data through broken authorization
  • Stored XSS in authenticated or sensitive areas
  • CSRF that changes password, email, billing state, or security settings
  • Accessing admin-only functions without proper authorization
  • High-impact business logic flaws with real abuse value

Example non-eligible reports

Examples generally not rewarded unless paired with meaningful impact:

  • Missing security headers by themselves
  • Logout CSRF
  • Harmless clickjacking
  • Self-XSS affecting only the reporter
  • Rate-limit observations without a demonstrated bypass
  • Verbose error messages without security impact
  • Content, SEO, formatting, or UX issues unrelated to security

What to include in a report

Please include:

  1. A short title
  2. The affected URL, endpoint, or feature
  3. A description of the issue
  4. Step-by-step reproduction instructions
  5. Any prerequisites required
  6. Screenshots or a small proof of concept if useful
  7. A realistic description of the impact
  8. Suggested remediation, if known
  9. A note confirming whether any user data was accessed

Response targets

We aim for:

  • Initial acknowledgement within 3 business days
  • Triage within 7 business days
  • Faster handling for critical and high-severity issues
  • Reward decisions after validation
  • Payment within a reasonable time after final review and payment coordination

These are targets, not guarantees.

Duplicate policy

Only the first valid report of a unique issue is generally eligible for a payout.

Later reports may still be helpful, especially if they:

  • Demonstrate broader impact
  • Provide a clearer proof of concept
  • Show a distinct exploitation path

Disclosure policy

Please do not publicly disclose a vulnerability before we have had a reasonable chance to investigate and remediate it.

As a general guideline:

  • Critical and high-severity issues: please allow at least 60 days
  • Medium and low-severity issues: please allow at least 90 days

If an issue is fixed sooner, we may approve earlier disclosure.

Payment terms

Rewards are offered at Bazinet.net’s discretion. Submission of a report does not guarantee payment.

We reserve the right to:

  • Decline payment for duplicates, out-of-scope reports, or non-actionable findings
  • Adjust severity after internal review
  • Request clarification before making a final decision
  • Thank or credit researchers publicly only with their permission

Recognition

We may publicly thank researchers who submit valid reports, with their consent.

Possible recognition may include:

  • Name
  • Handle
  • Personal site or researcher profile

Short version

If you find a real security issue affecting bazinet.net, report it privately to admin@bazinet.net. Good-faith testing under this policy is authorized, and valid reports may qualify for rewards based on severity.

Thank you for helping keep Bazinet.net safer.

Advertisement

Put this into practice

Create a free, zero-knowledge vault and give every account a strong, unique password.