Responsible Disclosure Policy

Our Commitment

Reqursor Technologies welcomes reports of security vulnerabilities from researchers and customers. Our Acceptable Use Policy and Terms of Service prohibit attacking, probing or gaining access to systems you have no written permission to test, and our security page asks you not to test our systems without our written permission. This policy keeps those rules. It explains how to report a finding, how to ask for permission to test, and what you can expect from us.

Safe harbor: Testing is authorized only where we have given you written permission, and only within that permission. If you act in good faith, follow this policy and stay within the written permission, Reqursor treats your testing as authorized for the purposes of our Acceptable Use Policy and Terms of Service. We will not bring a civil claim against you for that work, and we will not report it to law enforcement unless the law requires us to or your conduct goes outside this policy. If you come across a vulnerability by chance, without testing, we will not take action against you for reporting it in good faith, as long as you stop and report it as described below.

To stay within this policy, and within the law, we ask that you:

• Ask for written permission before you test anything: email [email protected] with the asset you want to test and what you plan to do. Until you have that permission, do not test.
• Act proportionately and use the least intrusive means necessary to demonstrate a finding, in line with the NCSC Coordinated Vulnerability Disclosure guideline.
• Access only your own test accounts and data, and do not attempt to reach another customer’s data.
• If you encounter personal data, stop immediately; do not access, copy, download, retain, or disclose it, and tell us at once.
• Report to us first and give us reasonable time to fix the issue before disclosing anything publicly.
• Do not run denial-of-service, volumetric, or high-volume automated tests, or otherwise degrade availability for others.

There is one limit we must be honest about. Under Dutch law, no private company can grant immunity from criminal prosecution. Unauthorized access to a computer system is an offense under article 138ab of the Dutch Criminal Code (computervredebreuk), and the decision whether to prosecute rests with the Public Prosecution Service (Openbaar Ministerie), which Reqursor cannot bind. The commitments above are promises about what Reqursor itself will and will not do; they cannot bind the State or waive the rights of third parties, including our customers. A published policy and clear, good-faith compliance are, however, circumstances the Public Prosecution Service weighs, and following this policy is the best protection available to you. For the same reason, if your report or our own monitoring shows that personal data was accessed, we may be required to notify the affected customer and, where we act as controller, the Autoriteit Persoonsgegevens under article 33 of the GDPR. That is a data protection duty we cannot waive. It is separate from, and does not amount to, reporting you to law enforcement or bringing a claim against you, and it is a further reason to stop the moment you encounter personal data and to tell us at once.

Scope

• Reqursor Platform: In scope. Written permission; own account only
• Reqursor Development: In scope. Written permission; your own install
• License portal and license server: In scope. Written permission first
• Credits relay: In scope. Written permission first
• Our websites: In scope. No DoS or heavy scanning
• Other customers’ systems and stores: Out of scope. Only with that customer’s written consent, never through us
• Hosting and software providers: Out of scope. Report to that provider
• Physical offices and staff: Out of scope. Never in scope
• Denial-of-service / volumetric: Out of scope. Never permitted
• High-volume automated scanning: Out of scope. Out of scope

In scope means we want to hear about it. It does not mean you may test without asking: testing needs our written permission, as described above. In your request, name the exact hostnames or the installation you want to test. A customer’s own systems and stores may be tested only with that customer’s written consent: under our Data Processing Addendum the customer is the controller of the data in them, and Reqursor cannot authorize access to it on their behalf.

Out of Scope

The following are outside this policy. We may close reports about them without action unless you can demonstrate a realistic, real-world impact:

• Self-XSS that cannot be used against another user.
• Missing security headers with no demonstrated impact.
• Missing or misconfigured SPF, DKIM, or DMARC records.
• Clickjacking on pages with no sensitive action or state change.
• Outdated library versions with no working proof of concept.
• Rate limiting on unauthenticated or low-risk endpoints.
• Output of automated scanners submitted without analysis.
• Social engineering, phishing, and attacks on our staff.
• Physical attacks against offices, hardware, or people.
• Findings that need a compromised device or a man-in-the-middle position.

How to Report

Send your report, or your request for permission to test, to [email protected]. Please keep each report to a single issue, and never include live passwords or keys: if a credential has leaked, tell us which one and change it first.

1. Prepare: Keep each report to one issue. Give a clear description, name the affected product, page, URL or version, and share your own assessment of the impact.
2. Reproduce: Include exact, minimal steps to reproduce the finding, together with supporting evidence such as requests, logs, or screenshots.
3. Send: Email [email protected]. We do not publish an encryption key yet, so do not encrypt your report with a key we cannot decrypt.
4. Protect data: If you reach personal data, stop at once. Do not copy, download, or retain it: a table name or a single record is enough to prove access.
5. Coordinate: Give us reasonable time to fix the issue, and agree timing with us before you disclose anything publicly.

What to Expect

• Promptly: Acknowledgement. We confirm we have received your report.
• After acknowledgement: Triage. We assess the finding and give it an initial severity.
• After triage: Remediation plan. We share a plan and a target date driven by the severity of the issue.
• By agreement: Fix and retest. We agree the remediation timeline with you, not fixed per-severity dates.
• After a fix: Coordinated disclosure. Please do not publish before we have had reasonable time to fix the issue, and agree the timing of any publication with us.

No bug bounty, and no public credit: Reqursor does not run a bug bounty or any other reward. We also do not publish security advisories or credit reporters publicly, so we cannot offer public credit. If that matters to you, please weigh it before you report.

Reqursor Technologies, Rotterdam, the Netherlands, KvK 42184274. Send security reports and requests for permission to test to [email protected]; legal questions go to [email protected] and customer support to [email protected]. This policy is governed by Dutch law; the competent court is the District Court of Rotterdam (Rechtbank Rotterdam).