📆 April 9, 2018

Add security.txt to your site, with correct contact details inside the file, so that people reporting security issues won't have to guess where to send the reports to. Using a real example, I'll show you why having such file is a good idea.

Sometimes, people find security vulnerabilities, and they would like to report them so the vendor or the developer can fix them. That was the case for me in December 2017 as well.

The vulnerability

On Saturday, December 16, I reported a Cross-Site Scripting (XSS) vulnerability on a well known site Alza.cz (also known as Alza.co.uk and Alzashop.com). They were echoing the current URL to the Not Found page without any sanitization, between <script> and </script> tags, to an event parameter they send to Google Analytics for tracking. The code for https://www.alza.cz/foo looks like this:

ga('send', 'event', 'Error404', 'http://www.alza.cz/foo');

Then when you loaded https://www.alza.cz/foo?');+alert(1);+// in your browser, an alert popped up:

ga('send', 'event', 'Error404', 'https://www.alza.cz/foo?'); alert(1); //');

It's quite hard to demonstrate the possibilities of an injected JavaScript with just alert(1), so I've built a proof-of-concept demo. When a user would click the malicious link, the login window would show up and when the user would try to enter their login credentials or submit the form, they would receive a “phishing demo” message instead. No data would be submitted. I could change the action attribute of the login form to submit the password to my server, but that was not the point of the demo.

The malicious demo link (could be shortened with a URL shortener):


At last, the warning message over the login form:

Phishing demo

Reporing the issue

To report the problem I first had to find the right person to report it to. You don't want to report security issues to customer support, they wouldn't know what to do with it. After some googling I found Vladimír Dědek, the director of web & mobile development. But who's Vladimír? How does he react to reports like this? Will he understand the report at all? Some more google queries, and here I was, watching a video interview (in Czech) where Vladimír talks with Jirka Rostecký about development-related things and stuff. Vladimír was the guy I was looking for. I've sent him a short email with the issue description and got back to whatever I originally intended to do.

Vladimír's response arrived the next day (on Sunday!) morning. Alza has fixed the vulnerability in a few days, they handled the report nicely, emails were also nice, so thanks Alza! Their quick response was similar to that of DomainTools – they fixed a similar vulnerability on Friday before Christmas.

Guess what took the most time: find the bug, prepare the demo, or find someone to report the issue to?

Yeah, you're right, I burned most of the time by trying to find the right contact. Must be someone who will understand the issue, and not scramble their lawyers instead. Some time ago, when I found a leaked data from a Czech hosting company (in Czech) just by a lucky accident, it also took me quite a while to find the right contact. I even asked their customer support to provide a dedicated security email and their response was “there's none” and that I should just send the report unencrypted to their support email and they'll get back to me. I kind of understand why companies do it, on the other hand it might discourage someone and then they may do things they'll regret later on.

Look, I get it, you don't want your “About” or “Contacts” page to have “Report security issues here” link but how to tell the potential reporters where to report their findings? You probably don't want people to ask for security contact details on Twitter like me, when I wanted to report issues with AlwaysOnSSL certification authority. Contacts in whois listing are often private or it's not the right people for security matters.


Ed Foudil tried to tackle this. He has created a draft for security.txt (the full name is “A Method for Web Security Policies”, soon to be published as an RFC hopefully), which in short is a file called security.txt with security contacts where to send your reports to.

The security.txt file has to be at a predictable location, for web sites it's the /.well-known/ directory. That directory is defined in RFC 5785 and serves as a base directory for “well known” locations. It's used by e.g. KeyBase and Let's Encrypt certification authority for domain ownership validation and some more. The path to my security.txt file is https://www.michalspacek.com/.well-known/security.txt, and there's a recommended redirection in place for /security.txt. On internal hosts or file systems you can place the .security.txt (with a leading dot) directly in the root directory.


The file uses directives and values, each directive can only have one value (e.g. an address). You can add more identical directives but with different values, each on a separate line which must end either with CRLF or just LF characters. The file must contain at least one Contact directive with an email address, a phone number, or a web page with more info. My Contact directives look like this:

Contact: https://www.michalspacek.cz/kontakt
Contact: https://www.michalspacek.com/contact

I've added a link to my Twitter and Facebook too, I've omitted them here for simplicity.


Using Encryption directive you can (and should) add a link to your PGP key which can be used to encrypt the report. My directive:

Encryption: https://www.michalspacek.cz/key.asc


You can sign the security.txt file (for example by running gpg --detach-sign security.txt) and add the signature to a file called security.txt.sig or so. Place the file to the /.well-known/ directory as well and add a link using a Signature directive. Don't forget to update the signature whenever you change the file, even in the slightest.


With the Policy directive, you can add a link to your security policy and/or disclosure policy.


If you have a “Hall of Fame” page listing people or companies that disclosed security issues and worked with you to fix them (like what T-Mobile CZ has), you can add a link to such page here. It doesn't need to be complicated, check what AlwaysOnSSL has in their security.txt.


Hiring security professionals? Add a link to open positions or job description here.

✅ Add security.txt

Even if you're too lazy to do anything today, you can still at least add the file (provided you know where the security reports should be sent to) and you can tick off the task “improve relationship with a security community and make reporting security issues easier”. And even if you're busy today just add the file tomorrow. You never know when I'll be looking for one :-)

The Contact directive is mandatory but I'd suggest adding Encryption directive too (if you have an encryption key). Of course you can add the other directives too.

There's a simple file generator at securitytxt.org, you can also check my file, Have I Been Pwned?, Report-URI, and Google has one, 1Password and Facebook as well. This Czech webhosting company and this Swiss bank have security.txt too.

Michal Špaček

I build web applications and I'm into web application security. I like to speak about secure development. My mission is to teach web developers how to build secure and fast web applications and why.

Public trainings

Come to my public trainings, everybody's welcome:

PHP application security
(June 13–14, 2018 Praha)

HTTPS for developers and admins
(June 15, 2018 Praha)