Security Policy

dlptest.com is a public resource for testing Data Loss Prevention products. Because the entire purpose of the site is to receive, inspect, and discard sensitive-looking traffic, several pieces of expected security behavior look unusual at first glance. This page describes what is and isn't a vulnerability, how to report something that genuinely is, and what to expect after you do.

Reporting a vulnerability

Email brian@dlptest.com with the subject prefix Security: and include:

Encrypted reports are not currently supported. If you need to send encrypted material before we can arrange a key, contact us first to coordinate.

What to expect after reporting

In scope

Explicitly out of scope (by design)

The following are intentional design decisions, documented elsewhere on this site. Reports on these are not considered vulnerabilities and will be closed as working as intended.

The public FTP credentials on /ftp-test/

The FTP server username and password are deliberately published on that page so anyone can run anonymous DLP test uploads. The host (ftp.dlptest.com) is a separate, segregated environment; uploaded files are automatically deleted after roughly 10 minutes; and an IP block list mitigates obvious abuse. Republishing the credentials is not a disclosure.

/api/http-post accepting arbitrary payloads

This endpoint is the primary purpose of the site. It deliberately accepts any request body — SQL-injection-shaped strings, fake credit card numbers, malware test files, binary blobs, anything — reads the bytes so DLP appliances and proxies can inspect them in flight, and then immediately discards them. Nothing is logged, stored, or forwarded. Sending an attack-shaped payload to this endpoint and receiving a 200 response is the expected behavior, not a vulnerability.

Generator output being predictable for a given seed

The /generate/ tool uses a seeded pseudo-random number generator so that practitioners can reproduce the exact same dataset by re-using a seed. This is a deliberate feature for repeatable test cases. The outputs are synthetic and do not correspond to any real person, account, or institution.

Self-impacting input rendering on /generate/

The field-name input on the data generator accepts arbitrary text. The resulting dataset is only ever downloaded by the user who entered the field name — there is no cross-user vector. Spreadsheet formula characters in field names are already sanitized in CSV and XLSX exports; HTML-shaped input is rendered with textContent and cannot execute.

Sample data and pre-generated downloads matching real-looking PII

The contents of /sample-data/ and the larger R2-hosted test files are synthetic patterns deliberately designed to satisfy DLP detection rules (valid Luhn check digits, SSN area-group conformance, etc.). The values are fabricated and do not correspond to real people. Hosting them publicly is not a data leak.

Email enumeration on subscribe

/api/subscribe/ returns a distinct 409 response for an already-subscribed email. This is a deliberate UX signal on a public newsletter signup so users understand why a resubmission didn't change anything. The site does not consider this enumeration sensitive.

Third-party services we depend on

Issues in Cloudflare's infrastructure, the Railway-hosted subscribe upstream, Microsoft 365 (contact-form email), Google Tag Manager, or any other vendor we integrate with should be reported directly to those vendors. How dlptest.com integrates with them is in scope; the underlying services themselves are not.

Safe harbor

Good-faith security research is welcome on this site. We will not pursue legal action against, support claims against, or report to law enforcement researchers who:

Activities that fall outside good-faith research — including but not limited to data destruction, denial-of-service attempts beyond a brief proof of concept, persistence on systems, and lateral movement — are not authorized.

Acknowledgments

Researchers who report responsibly are gratefully thanked. As credited disclosures accumulate, this section will be updated with a public list.

Policy machine-readable summary

A security.txt file (RFC 9116) is published at the canonical location and points back to this policy. It is the appropriate destination for automated security tools and bug-bounty platform scrapers.

Last updated: 2026-05-25. The security.txt file expires on 2027-05-25 and will be re-issued before then.