30 days
Resolution target
Safe harbor
For good-faith research
📩 Report a security issue
Email us with full technical details. We read every report and respond within 48 hours.
Email [email protected]
How do I report a security vulnerability?
Send an email to [email protected] with the technical details. We monitor this address daily, including weekends.
If you cannot use email, you may also message us on WhatsApp at +92 333 4882726 — but please do not include sensitive vulnerability details in chat messages. Use email for the actual report.
For machine-readable security contact details, see our security.txt file (RFC 9116 standard).
What information should I include?
The more detail you can give us, the faster we can verify and fix the issue. A useful report includes:
- Vulnerability type — e.g. XSS, SQL injection, CSRF, IDOR, auth bypass, server misconfiguration
- Affected URL or endpoint — the exact page, parameter or API method
- Step-by-step reproduction — how to trigger the issue from a clean session
- Impact — what an attacker could do if this stayed unfixed
- Proof-of-concept — code, request payload, or screenshot showing the issue (please redact any real user data)
- Suggested fix if you have one (optional but appreciated)
- Your name and contact — so we can credit you if you want, and reach you with follow-up questions
Please do not include real customer data in your report. If you accessed any customer data while investigating, tell us — we will help you delete it safely.
What is our response timeline?
Our commitments after receiving a valid report:
- Within 48 hours — we acknowledge receipt and confirm the vulnerability is being investigated
- Within 5 business days — we tell you whether we can reproduce the issue and our assessment of its severity
- Within 30 days — we aim to deploy a fix to production for any confirmed High or Critical issue. Lower-severity issues may take longer; we will keep you informed
- After the fix — we notify you, and (with your permission) credit you in the hall of fame below
If a fix requires more than 30 days, we will explain why and give you a realistic timeline.
Is good-faith security research protected?
Yes. If you act in good faith — research a vulnerability, report it privately, do not access or alter customer data, and do not disrupt our service — we will not pursue legal action against you under computer-misuse or contract law.
This safe-harbor commitment applies as long as you:
- Make a genuine effort to avoid privacy violations, service disruption, and destruction of data
- Only interact with accounts you own, or with explicit permission of the account holder
- Report the issue to us before public disclosure, and give us reasonable time to fix it
- Do not extort, threaten or demand payment as a condition of disclosure
- Comply with all applicable laws
We follow the principles of coordinated vulnerability disclosure: you report privately, we fix, you can publish after the fix is deployed.
What is in scope for security research?
The following assets are explicitly in scope for security testing under this policy:
jpsheet.com and all its public subdomains- The
/api/ endpoints (rate-limited; please do not flood)
- The admin login flow at
/admin/login.php (please do not brute-force; we have detection)
- The Stripe and PayPal payment flows (reproduce on test orders only — do not place real fraudulent orders)
- The chatbot at
/api/chatbot.php
What is out of scope?
The following are not covered by this policy. Reports about these will be politely declined:
- Third-party platforms we use but don't control — Stripe, PayPal, Google, Facebook, Cloudflare, YouTube. Report directly to them.
- Denial-of-service attacks (DoS / DDoS). Do not test these. We will treat this as malicious.
- Social engineering attacks against JP Sheet staff or our suppliers
- Physical attacks against our offices or staff
- Issues that require a physical compromise of the user's device (e.g. malware, shoulder-surfing)
- Spam, mass automated submissions, or automated scans without prior coordination
- Outdated browser warnings, missing security headers on assets that don't carry risk, or theoretical issues without practical impact
- Self-XSS (an attack requiring the victim to paste code into their own console)
- Issues in the user's own browser — extensions, malware, browser bugs
Do you pay bug bounties?
We do not currently run a paid bug bounty program. We do offer:
- Public credit in our hall of fame (below) with your name and a link of your choice
- A personal thank-you from our team
- JP Sheet service credit at our discretion for high-impact reports (verification reports, translations, manual searches)
- A reference letter for your portfolio or CV if you'd like one
If you depend on bug-bounty income, this isn't the right program for you — and that's fine. We'd rather be honest about what we can offer.
Security researcher hall of fame
Researchers who have helped us improve JP Sheet's security. Listed with their permission, in chronological order. Want to be added here? Report a valid vulnerability.
We're a young program — this list will grow. You could be the first.
I'm a customer — what if I have a non-security issue?
Please use our regular support channels — they are faster for non-security problems:
Reserve [email protected] for actual security vulnerabilities — it keeps our queue clear so real issues get fast attention.
Last updated: 29 May 2026 · This policy applies to JP Sheet and its subdomains. Operated worldwide since 1982.
