security.txt 101: How to create it, where to put it, and why it helps your ecommerce security

If someone finds a serious security bug on your site today, do they know how to reach you? If they have to dig through WHOIS records or random contact forms, there’s a good chance they’ll give up—or go public in a way that hurts you. That’s exactly the problem security.txt was created to solve.

What is a security.txt file?

security.txt is a small text file, published at a well‑known location on your domain, that tells security researchers how to report vulnerabilities to you in a clear, standardized way.

• It lives at:
  • https://yourdomain.com/.well-known/security.txt (preferred)
  • Optionally also at https://yourdomain.com/security.txt as a fallback.
• It follows an Internet standard (RFC 9116) that many security tools and researchers already know to check.
• It’s similar in spirit to robots.txt, but instead of crawl rules, it exposes security contact and policy information.

The goal: make it easy and fast for ethical hackers and “finders” to tell you about problems so you can fix them before attackers exploit them.

Why bother with security.txt? Practical benefits

Adding security.txt is a simple change, but it sends a strong signal about your security posture.

Some concrete benefits:

• Easy vulnerability reporting
  Researchers don’t have to guess email addresses or ping random social accounts; they can go straight to /.well-known/security.txt and find the right contact info.
• Fewer unreported or “dropped” bugs
  When people don’t know how to contact you, they may never report serious vulnerabilities—or they might post them publicly, increasing risk.
• Shows you take security seriously
  Governments, large organizations, and platforms are starting to recommend or adopt security.txt as a best practice. Having it in place demonstrates transparency and willingness to engage with researchers.
• Standardization for tools and automation
  Security scanners and platforms (Cloudflare, bug bounty providers, validators) can automatically discover your security.txt and surface details to their users.

For an ecommerce site, this is an especially useful signal—your store handles payments, customer data, and logins, making you an attractive target. Anything that shortens the path between “someone found a bug” and “you’ve fixed it” reduces risk.

What goes inside a security.txt file?

The standard defines several fields. You don’t have to use every possible directive, but there are a few core ones you should almost always include.

At minimum, plan to add:

• Contact: how researchers should reach you
  • Example formats: Contact: mailto:security@yourdomain.com or Contact: https://yourdomain.com/security-report.
  • This should be a monitored inbox or form, not a dead alias.
• Policy: link to your vulnerability disclosure policy
  • Example: Policy: https://yourdomain.com/vulnerability-disclosure.
  • This page explains what kind of testing is allowed, what you expect from researchers, and how you handle reports.
• Expires: when the information should be considered stale
  • Example: Expires: 2026-12-31T23:59:59Z.
  • This forces you to review and update your contact info periodically so researchers aren’t using old data.

Optional but recommended fields:

• Encryption: link to your PGP public key or other method for encrypted communication
  • Example: Encryption: https://yourdomain.com/pgp-key.txt.
  • Useful if you expect sensitive reports and want them encrypted.
• Acknowledgments: where you thank researchers
  • Example: Acknowledgments: https://yourdomain.com/hall-of-fame.
  • Helps build goodwill with the security community.
• Preferred-Languages: languages you accept reports in (e.g., Preferred-Languages: en, es).

Each directive appears on its own line, and the file remains plain text—easy to read and parse.

How to create a security.txt file step-by-step

You can create the file manually or use a generator. The process is straightforward.

Step 1: Decide on your security contact and process

Before touching the server:

• Choose a dedicated email address (for example, security@yourdomain.com or security-report@yourdomain.com) or a secure web form.
• Decide who will read and triage these reports (security team, dev lead, ops), and set internal expectations for response times.

If you already have a public Vulnerability Disclosure Policy (VDP) or a bug bounty program, note the URL—you’ll reference it as the Policy field.

Step 2: Draft the security.txt content

Create a new plain text file named security.txt locally, and add something like:

Contact: mailto:security@yourdomain.com
Contact: https://yourdomain.com/security-report
Policy: https://yourdomain.com/vulnerability-disclosure
Encryption: https://yourdomain.com/pgp-key.txt
Acknowledgments: https://yourdomain.com/security-hall-of-fame
Preferred-Languages: en
Expires: 2026-12-31T23:59:59Z

Adjust URLs and dates for your site. Keep lines simple and strictly in the format expected by RFC 9116.

If you don’t want to write this from scratch, you can:

• Use an online generator such as securitytxt.org or similar tools, which guide you through fields and produce a valid file.

Step 3: Upload the file to /.well-known/

On your web server or hosting platform:

• Create the directory: .well-known at the root of your domain if it doesn’t exist yet.
• Upload security.txt into that directory.

The file should then be accessible at:

• https://yourdomain.com/.well-known/security.txt.

Optionally, you can also put a copy at https://yourdomain.com/security.txt, but /.well-known/security.txt is the primary standard location.

If you’re using a CDN or security platform like Cloudflare, some offer built‑in ways to manage security.txt directly in their dashboard.

Step 4: Test and validate

After uploading:

• Visit the URL in your browser and confirm the file loads correctly (no extra HTML, headers, or formatting).
• Use a security.txt validator tool to check for syntax and standard compliance.
• Make sure any links (policy page, PGP key, contact form) work and are secure (HTTPS).

If you sign the file with an OpenPGP cleartext signature, note that some guidance recommends this to add authenticity—so researchers know the file wasn’t planted by an attacker.

Keeping your security.txt useful over time

A security.txt file is not “set and forget.” To keep it helpful:

• Update contact info and policy URLs whenever you change teams, addresses, or disclosure processes.
• Refresh the Expires date regularly (typically less than a year ahead), so researchers know the file is current.
• Review the file at least every few months as part of your security checklist—just like certificates, backups, and access control.

You can integrate this into your operations:

• Add security.txt review to your deployment or quarterly security review checklist.
• Track inbound reports separately so you see how often researchers use this path and how quickly you respond.

Why ecommerce sites should adopt security.txt

For ecommerce businesses, implementing security.txt is a small, high‑ROI step:

• You handle sensitive data: customer accounts, saved payments, order history.
• You’re a likely target for carding, credential stuffing, and web exploits.
• Ethical hackers actively scan and test ecommerce sites; giving them a clear channel helps you fix issues faster.

By putting a simple text file at /.well-known/security.txt, you make your vulnerability disclosure process discoverable in seconds, reduce unreported issues, and show customers and partners that you take security seriously.

If your ecommerce stack is based on OpenCart, Magento, or similar platforms, you can even add this as a standard hardening step in your deployment checklist—alongside HTTPS, proper headers, WAF rules, and secure payment configuration

Here’s a simple, standards‑aligned security.txt you can use for webocreation.com based on the email you provided.

You’ll put this exact text in a file named security.txt and upload it to https://webocreation.com/.well-known/security.txt (and optionally also https://webocreation.com/security.txt).

Contact: mailto:webocreation.com@gmail.com
Contact: https://webocreation.com/contact-us/
Policy: https://webocreation.com/privacy-policy/
Preferred-Languages: en
Expires: 2029-12-31T23:59:59Z

Note: Webocreation currently does not have a bug bounty program or any kind of financial compensation for valid reports. However we are happy to credit researchers with their name and a link to a professional profile (e.g. linkedin) on our Hall of Fame for valid reports that lead to corrective action.

A few notes so you can adjust as needed:

• Contact:
  • You already have webocreation.com@gmail.com, which is good.
  • If you have a contact page or a specific “report a security issue” page, keep or update the second Contact: line to that URL.
• Policy:
  • If you don’t yet have a vulnerability disclosure policy page, you can either:
    • Create one at /vulnerability-disclosure/ and keep this line, or
    • Temporarily remove the Policy: line until that page exists.
• Preferred-Languages:
  • Right now it’s set to en. Add more codes if you’re happy to receive reports in other languages (e.g., en, ne).
• Expires:
  • Update this date once or twice a year so researchers know the file is current. It should be an ISO 8601 timestamp in UTC (like above).

Once it’s uploaded, you can test by visiting:

• https://webocreation.com/.well-known/security.txt

and checking that:

• It loads as plain text (no HTML).
• The lines look exactly as above, each on its own line.

Adding a security.txt file to website is a small, high‑impact step that makes it easier for ethical hackers and security researchers to help you, instead of harm you. By publishing a simple text file at /.well-known/security.txt with clear contact details, a disclosure policy link, preferred languages, and an expiry date, you give finders a standard, well‑known place to learn how to report vulnerabilities responsibly. This shortens the path from “bug discovered” to “bug fixed”, reduces the chance that serious issues go unreported or are disclosed in risky ways, and shows customers, partners, and platforms that you take security communication seriously. For any ecommerce site—especially one handling logins, payments, and customer data—implementing security.txt belongs alongside HTTPS, secure checkout, and regular security reviews as part of basic hardening.