Security policy

Last updated: October 12, 2026

dlpbench.com is a free bench for testing DLP. We intentionally accept traffic that looks like a data leak so your controls can see and react to it. Behavior that would look odd on a normal production site is often by design here.

Below: what we do not treat as a vulnerability, what findings we will review, and where to write. Usage rules and visitor information are in the Terms of use.

How to report a security issue

UI bugs and product ideas belong on the contact form. Use the address below only for security matters.

To: info@dlpbench.com

Subject: Security: short description

In your message, it helps to include:

1. what you found and why it matters;
2. how to reproduce it (curl or a short script);
3. which host or component is affected;
4. a name or handle for acknowledgment—if you want one.

We will confirm receipt, assess the finding, and fix issues according to severity. Timing depends on impact; that is a practical target, not a contractual SLA.

Do not run denial-of-service attacks, delete other users’ test files, or pivot from our service onto the hoster’s infrastructure or unrelated third-party CDNs and services.

We welcome good-faith research consistent with this policy. This page states the operator’s intent toward researchers; it is not a separate legal safe harbor or warranty.

What is not a vulnerability

For the items below, our reply is: “working as intended.”

Open FTP username and password

Credentials on the FTP test page are published on purpose. Finding or reprinting them is not an incident.

Test POST accepts any body

/api/http-post/ is the main bench channel. You may send JSON, form data, SQL-injection-looking strings, test card numbers, or a binary file: the server reads the body and responds with success. If your browser has a session cookie, the result is briefly visible only to you. A 200 on a suspicious-looking request is normal bench behavior, not a hole.

Shared short-lived storage

On shared FTP and object channels, users are not isolated from each other until cleanup. Retention is short; we rate-limit requests from a single IP. Do not upload anything confidential there.

“Real-looking” SSN, IBAN, and card numbers in samples

Numbers are chosen to pass format checks (checksums, Luhn, and similar). They are not tied to living people. Publishing them is not a database leak.

No filter for “suspicious” content on test POSTs

If we blocked typical test payloads at the door, the DLP exercise would stop working.

What is in scope

• the dlpbench.com site and its application;
• no-ssl.dlpbench.com and the web side of s3.dlpbench.com;
• access to data beyond what is intentionally public—for example, operator mail, site files outside test directories, or configuration secrets;
• XSS and CSRF that affect other visitors;
• misconfiguration that exposes source with secrets, .env files, or private directories.

Issues in Fornex infrastructure, third-party CDNs, or other vendors belong with those owners. How we embed a third-party service on our pages is fair game to report to us.

security.txt

/.well-known/security.txt (RFC 9116) lists the same email info@dlpbench.com and a link to this page.