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:
- A description of the issue and its potential impact.
- Reproduction steps detailed enough to verify (a curl command or a short script is ideal).
- The affected URL, endpoint, or component.
- Your name or handle if you'd like to be credited after a fix ships.
- Optional: a suggested fix or relevant references.
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
- Acknowledgment of receipt within 3 business days.
- An initial triage decision (in scope, out of scope, duplicate, or needs-more-info) within 7 business days.
- A fix timeline scaled to severity. Critical issues affecting other users' data or the integrity of the site target a fix within 14 days; lower-severity items may take longer.
- Public acknowledgment after a fix ships, if you'd like to be credited.
In scope
dlptest.com,www.dlptest.com, andstaging.dlptest.com(the Astro on Cloudflare Workers application).- The
/api/*endpoints (HTTP POST acceptor, data generator, contact, subscribe). - Authentication, session handling, and any user-supplied input that affects another user.
- Data exposure that goes beyond what is intentionally public (see below).
- Misconfiguration of Cloudflare WAF rules, rate-limit rules, or other security controls that the site relies on.
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:
- Make a good-faith effort to avoid privacy violations, service degradation, and data destruction.
- Only interact with accounts and data they own or have explicit permission to access (note: this site has no user accounts).
- Do not pivot to attack other systems hosted by Cloudflare, Railway, Microsoft, or anyone else.
- Report findings privately to the address above and give us reasonable time to remediate before any public disclosure.
- Stay within the scope defined on this page.
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.