Is .well-known/acme-challenge/ an XSS risk

I use to check my website of any possible security issue, the site gives me that /.well-known /acme-challenge/ could be an XSS so that an attacker can inject JavaScript into the victim’s browsers, which will execute under the vulnerable domain.

the website show an example with html tage like<h1>something

I tried the example and i found "<h1>something" is included in the page.

Is that really a security risk?

please let me if it is or not?


If putting some HTML in the URL results in it being echoed back to the viewer as HTML, that’s potentially an XSS risk. When you put <h1>something in the URL, do you see <h1>something when you view it, or do you see “something” rendered as a heading? If the former, everything is probably fine; if the latter, there’s potentially a problem and you should investigate it further (try <script> etc).

That’s unlikely to be related to Let’s Encrypt, though. /.well-known/acme-challenge/<h1>something isn’t a valid ACME HTTP-01 challenge URL, so if you request it, you’re most likely hitting your webserver’s error page. It’s easy enough to imagine a custom error page with some content like “Page [URL] not found” that could be vulnerable to reflected XSS if it’s implemented incorrectly.


Yes it is seen like <h1>something not “something”, even I use <script>alert("hi");</script> it is shown as a text not executed.

Thanks for your clarification, because I want to make sure it is not a risk, so I can leave it open.

so in this case this is not an XSS risk.

Hi @moneer

did you insert that as

http://yourdomain/.well-known/acme-challenge / <script>alert("hi");</script>

or per Url-encoding (UTF-8):

http://yourdomain/.well-known/acme-challenge / %3Cscript%3Ealert(%22hi%22);%3C/script%3E

(added space to stop the decoding).

Test the last version. If <h1> is shown, it's critical. Then <script> may also work.

1 Like

I use this /.well-known/acme-challenge/%3Ch1%3Esomething it is retuned as <h1>somthing as h1 not executed.

Then I use test yours http://yourdomain/.well-known/acme-challenge / %3Cscript%3Ealert(%22hi%22);%3C/script%3E without added spaces.

it is returned as text <script>alert("hi");</script> not executed as a JavaScript too.


This can be used to defeat Content Security Policy, if you have that enabled.

If there were an actual XSS vulnerability in your web application, an attacker might add something like <script>window.location = '';</script>. Without Content Security Policy blocking unsafe inline scripts this would work, but with a proper Content Security Policy this would be blocked by browsers.

However, it’s likely your Content Security Policy would trust JavaScript files served from your own domain, so the attacker could change that to <script src="/.well-known/acme-challenge/"></script> and defeat that security measure.

(You’d think the fact that this file is served with a different mimetype would prevent it from being interpreted as JavaScript, but unfortunately browsers are very tolerant of JavaScript being sent as text/plain due to historical reasons.)

Now, you have to use Content Security Policy for this to even be an issue, and even if you do it’s minor in the grand scheme of things, but comprehensive security scanners are right to point out reflection of user input like this even if it is sanitized.

1 Like

The Header X-Content-Type-Options: nosniff should fix it for (almost) all browsers: X-Content-Type-Options - HTTP | MDN


The Header X-Content-Type-Options: nosniff should fix it for (almost) all browsers: X-Content-Type-Options - HTTP | MDN

I have that already activated n my nginx conf file.

1 Like

I understand now that because the script is not executed but only echoed in the browser, then that /.well-known/acme-challenge/ is save, and not an xss risk.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.