PrivShare

Security research

Security Research Hall of Fame

This page recognizes researchers who report valid vulnerabilities, and it sets out the rules, steps, and explicit boundaries for testing PrivShare safely. It complements the responsible disclosure policy.

Read the full disclosure policy

Researcher Acknowledgments

With their permission, researchers who report valid issues are credited here.

No researchers have been credited yet.

This is not a claim that PrivShare is free of vulnerabilities. When a valid report is received and the researcher permits acknowledgement, their name or handle is added here alongside a short summary and any related advisory.

Bug Bounty Stance

Transparency about what researchers can expect in return.

No paid bounty yet

PrivShare does not currently offer a paid bug bounty. That may change as the project grows.

You are welcome and will be credited

We welcome your research and will publicly credit valid reports with your permission. We never publish a name without consent.

How To Report

Follow these steps so we can reproduce and remediate quickly.

  1. 1Confirm the issue is in scope and reproduce it using only accounts, shares, files, and recipient email addresses that you control.
  2. 2Capture minimal, safe evidence: redacted requests or screenshots of your own test data. Never include real secrets, URL fragments, raw passwords, private keys, or signed transfer URLs.
  3. 3Email security@priv-share.com with a clear description, reproduction steps, impact, and the affected route or component.
  4. 4Give PrivShare a reasonable opportunity to investigate and remediate before any public disclosure.
  5. 5Tell us if you want public credit, and the exact name or handle to use. We never publish a name without permission.

Report by email to security@priv-share.com.

Testing Rules By Area

Each area lists what you may test and the explicit boundary that keeps testing safe and authorized.

Authentication

You may: Test login, session lifecycle, passkeys, TOTP two-factor, and OAuth flows against your own account.

Boundary: No credential stuffing, password spraying, or brute-forcing against accounts you do not own, and no login flooding.

Authorization

You may: Use two accounts you both control to probe owner-only routes and cross-account access to shares, files, and metadata.

Boundary: Do not access, modify, delete, or exfiltrate another real user’s data. Stop at proof using your own accounts.

Expiry

You may: Verify that expired shares cannot be retrieved even with a correct key verifier, using your own shares.

Boundary: Test only shares you created. Do not attempt to extend or tamper with other users’ lifecycles.

Burn-after-reading

You may: Test concurrent and duplicate retrieval of your own single-use shares to probe the atomic burn transition.

Boundary: Keep concurrency reasonable for a proof of concept. No sustained flooding or denial-of-service load.

API

You may: Fuzz share creation and retrieval inputs, validation, and error handling against your own shares.

Boundary: Throttle automated requests. No high-volume scanning that degrades service for others.

Encryption

You may: Inspect client-side AES-GCM and PBKDF2 handling, IV usage, key transport, verifiers, and wrapped-key metadata.

Boundary: Report cryptographic weaknesses privately. Do not publish exploit details before a fix is available.

File handling

You may: Test encrypted upload and download, signed CloudFront URLs, and encrypted metadata using your own files.

Boundary: Use only files you own. Do not attempt to reach other users’ object keys, blobs, or signed URLs.

ID enumeration

You may: Probe share identifier and opaque object-key enumeration and lifecycle disclosure on your own shares.

Boundary: If enumeration reaches another user’s data, stop immediately and report with the minimum safe evidence.

Race conditions

You may: Test time-of-check/time-of-use and concurrency on burn, expiry, and revocation using your own shares.

Boundary: Use bounded concurrency for a proof of concept. No sustained denial-of-service load.

XSS

You may: Test stored, reflected, and DOM cross-site scripting in fields you control, such as labels, folders, tags, and share content rendering.

Boundary: Use harmless proof such as a benign alert or a callback to a domain you own. No persistent payloads aimed at other users.

CSRF

You may: Test state-changing endpoints for cross-site request forgery protections using your own account.

Boundary: Target only your own account and session. Do not forge requests on behalf of other users.

SSRF

You may: Test server-side request handling on any surface that fetches or resolves a URL you can influence.

Boundary: Do not pivot into internal infrastructure, cloud metadata endpoints, or third-party accounts. Stop at proof.

Injection

You may: Test SQL, NoSQL, command, and template injection through inputs you control, using non-destructive payloads.

Boundary: No destructive payloads, no dropping or altering tables, and no exfiltrating other users’ data.

Information disclosure

You may: Look for leaked secrets, verbose errors, source maps, response headers, and metadata over-exposure.

Boundary: Do not hoard or publish disclosed data. Redact sensitive values and report promptly.

Global Guidelines And Safe Harbor

These rules apply to every area above. PrivShare does not pursue legal action against researchers who follow this policy and act in good faith.

  • Test only your own accounts, your own shares and files, and recipient email addresses you control.
  • Do not run denial-of-service, load, or destructive tests.
  • Do not send spam or unsolicited recipient email.
  • Do not use social engineering, phishing, or physical attacks.
  • Do not attack third-party providers except as strictly necessary to demonstrate a PrivShare issue with safe evidence.
  • Keep vulnerability details confidential until PrivShare has remediated or provided a disclosure timeline.

Incidents And Fixes

Confirmed and remediated issues are published as advisories.

No public PrivShare security advisories have been published yet.

When an issue is confirmed, fixed, and ready for responsible disclosure, it is published on the advisories page with impact, status, remediation, and credit where permission is given.

View security advisories

Keep reading

Explore the rest of the security documentation

Every security page links to the others so you can move through the full model without using the browser back button.

Back to security overview