# security.txt
# See: https://securitytxt.org/

Contact: mailto:security@pescheck.nl
Preferred-Languages: en, nl
Expires: 2026-12-31T23:59:59Z

# Responsible Disclosure Policy

Thank you for your interest in helping us improve the security of our products. We appreciate your commitment to ethical hacking and responsible security research.

While we do not have a traditional bug bounty program, we operate under a Responsible Disclosure Policy, reflecting our commitment to security and privacy. We welcome vulnerability disclosures from security researchers.

## Scope

The following systems are IN SCOPE for security testing:

- pescheck.io
- dashboard-staging.pescheck.io

The following systems are explicitly OUT OF SCOPE. Testing them is NOT authorised and reports against them will be closed:

- dashboard.pescheck.io (production)
- All other Pescheck domains, subdomains, and infrastructure
- Third-party services

## How to Collaborate with Us

To ensure a smooth and responsible disclosure process, please follow these guidelines:

1. **Report Promptly**: Send your findings to security@pescheck.nl
2. **Avoid Exploitation**: Do not exploit vulnerabilities beyond what is necessary for validation (e.g., no data extraction, modification, or third-party data access)
3. **Maintain Confidentiality**: Do not disclose vulnerabilities publicly until we have resolved them. Delete any obtained data as soon as possible
4. **One Issue Per Report**: File each finding as a separate report rather than bundling multiple unrelated issues
5. **Provide Clear Details**: Include enough information for us to reproduce the issue:
   - Affected URL and environment (production/staging)
   - System details (browser, OS, tooling used)
   - Description of the vulnerability
   - Step-by-step reproduction instructions
   - Working proof of concept (annotated screenshots, video, or request/response captures)

Reports we will NOT triage:

- Vague messages with no technical detail (e.g., "I found something critical, please contact me")
- Screenshot-only or image-only submissions with no written description or reproduction steps
- Reports against out-of-scope systems
- Duplicates of previously submitted issues

## Our Commitment to You

In return, we promise to:

- **Ensure No Legal Action** for reports submitted in good faith and in compliance with these guidelines
- **Respond Within Two Months** with an assessment and estimated resolution timeline
- **Keep Your Report Confidential**, unless legally required to disclose your information
- **Provide Progress Updates** throughout the resolution process
- **Acknowledge Your Contribution** (if desired) in any relevant disclosures
- **Offer a Reward** for the first valid report of an unknown vulnerability, including a spot in our Hall of Fame
- **Special Recognition**: Particularly clever or significant vulnerabilities may receive additional goodies and rewards at our discretion

## Excluded Vulnerabilities

Please note that the following issues do not qualify under our Responsible Disclosure Policy:

- Intentional directory listing for research/publication purposes
- SPF, DKIM, DMARC misconfigurations
- Automated scanner output without proof of exploitation
- Employee account compromise leading to vulnerabilities
- Non-sensitive cookie flags missing ('secure', 'http only')
- Reporting outdated software versions without an exploit or proof of concept
- Missing DNSSEC configuration
- Account-related issues (e.g., user enumeration, password reset abuse)
- Account recovery edge cases caused by the user's own actions outside our control (e.g., deleting the registered email account, losing all 2FA factors)
- Clickjacking, login/logout CSRF
- Protocol-level attacks (e.g., BEAST, BREACH)
- Fingerprinting, generic error messages
- Lack of security headers or non-critical HTTP settings
- EXIF metadata in user-uploaded images
- Public API documentation and OpenAPI/Swagger schemas (e.g., /docs, /openapi.json), which are intentionally public
- Disclosure of non-secret AWS identifiers in pre-signed S3 URLs (Access Key IDs starting with AKIA, bucket names, regions, expiry timestamps), which are public by design
- UUIDs or other opaque identifiers visible in URLs or HTML where authorisation is enforced server-side
- CSP nonce reuse within a single HTTP response (nonces are per-response, not per-tag)
- Resource abuse or "denial-of-wallet" attacks on authenticated endpoints accessible only to logged-in users, without a demonstrated unauthenticated exploit
- Self-XSS and other issues requiring the victim to attack themselves

We truly appreciate your efforts in helping us strengthen our security. Your expertise is invaluable, and we look forward to working with you.

Best regards,
The Pescheck Security Team