Security and responsible disclosure

Report suspected vulnerabilities privately and evaluate KDPika's controls with their stated limitations.

What you will learn

• Understand implemented controls without unsupported guarantees.
• Report an issue with a useful, redacted reproduction.
• Know the boundaries of safe research and disclosure.

Prerequisites

• Use only your own test accounts, products and Sandbox data.
• Read the threat model.
• Do not test another tenant or real buyer data.

Implemented controls

These statements describe code-backed controls, not a certification, penetration-test result, SLA or promise of complete protection. Current signature examples and test vectors expose interoperability limits honestly rather than disabling checks.

Report a vulnerability

Send a private email to hi@kdpika.com with the subject Security report — KDPika Licensing. Include:

• A concise description and affected public URL or component.
• A minimal reproduction using only your own synthetic Sandbox data.
• Expected versus actual behavior and a practical impact description.
• UTC time and redacted request IDs where useful.
• Your preferred contact method.

Do not include passwords, private signing keys, API secrets, activation tokens, bank-card data, other users' information or a bulk data dump. If sensitive evidence is unavoidable, ask for an agreed secure transfer method first. No public PGP key or encrypted-reporting channel is currently published; do not assume ordinary email is end-to-end encrypted.

Research boundaries

Stop when you have the minimum evidence needed. Do not access other tenants, disrupt service, flood endpoints, exploit payment systems, test social engineering, install persistence or alter/delete data you do not own. Contact support before any test that could exceed these boundaries.

This policy does not grant authorization for third-party provider testing. It does not promise a bounty, fixed response SLA or legal safe-harbor terms. Coordinate publication with the operator after reporting; do not disclose usable secrets.

security.txt

The public security.txt file follows the contact/policy format in RFC 9116. It points to the same reporting address and expires 2027-04-15. Expiry is a maintenance reminder, not a vulnerability-response deadline.

Operator and related notices

KDPika is operated by KHALED AL HARAZI, 11 AVENUE ARISTIDE BRIAND, 69190 SAINT-FONS, France. SIREN 899816219; SIRET 89981621900013. Contact hi@kdpika.com.

The operator's French address does not establish hosting geography. Review Privacy, DPA, subprocessors, legal notice and Status. Unknown provider/contract/region facts are not represented as confirmed certifications or EU-only processing.

Triage and recovery

1. Send the minimal private report.
2. Retain only your own necessary evidence securely.
3. Stop active testing if it risks other accounts or availability.
4. Coordinate clarification and any retest with the operator.
5. Remove disposable test artifacts when the investigation no longer needs them.

Expected result: a useful report reaches the published contact without exposing customers or secrets. A response-time commitment is not claimed.

Expected result

The reporting contact and policy are publicly accessible without an account, and security claims remain bounded by evidence.

Common mistakes

• Posting a usable secret in a public issue or feedback form.
• Demonstrating impact by accessing another customer's records.
• Assuming a certification or bounty exists because a security page exists.

Security notes

Use the API-key leak playbook for your own compromised management key. Suspected platform signing-key or tenant-isolation issues should be escalated privately to the operator.

Troubleshooting

Next steps

Read signed responses and the threat model, then validate your own integration in Sandbox.

Related

• Verification examples
• Offline mode
• Security and disclosure