I just noticed the default 404 page on one of my hosting accounts displays the requested URI.

<!--#echo var="REQUEST_URI" -->

I faintly remember hearing or reading that this is a potential vulnerability of some sort. However, it's hard to believe that a hosting provider would include this in their default 404 page if it was. So, is this a vulnerability or not?

4 Answers 4


Echoing the failed URI may enable an XSS attack (it depends on your site) as the URL could be constructed so that a piece of JavaScript is injected and runs on your site. As such this injected JavaScript would have access to the users cookies and if he was logged in it could be used to gain his private information in your system.

As long as the URI is sanitized (not allowed to include < or > for example) this should be fine.

You can test this with the following URI:

/doesnotexist/"--><script language="javascript">alert("hello world")</script>

It may need some tweaking to work (assuming it can be made to work)


However, it's hard to believe that a hosting provider would include this in their default 404 page if it was

Don't be so sure - I was with a very reputable host (or so I thought) who got hacked due to an unpatched vulerability and every single site on the host was deleted by the hacker. Their response - roll back to the last backup (72 hours old) and hope nobody notices.

That said, there have been 404 XSS attacks in the past but they usually only affect a single piece of software, not an entire system. I don't know how including the URI would affect such an attack though.

The ONLY thing I can think of, is if your web host was really poor, and I requested /gimma404.html?'); DELETE * FROM Users; -- and somehow the RequestURI was logged into a database and not escaped then you could have an SQL Injection attack.

  • 1
    Your security scenario would be a problem even if the URI was not echoed back. Its about logging the 404 and could happen even if you have a nice custom 404 page.
    – Kris
    Aug 12, 2010 at 10:22

So long as the REQUEST_URI is HTML Encoded there is absolutely no risk in displaying it.

Infact, it is generally good practice if the 404 page redirects to show the originally request URL so that the user can see exactly what they entered. This helps them to see if they made an obvious typo. This is the reason why so many default 404 pages do show this - it aids the user.


Any information that you don't want people to see is a security risk, my advice would be to never use default 404's not only do they look ugly and provide very little functionality but they can as you are asking cause security concerns.

Have a look at this site - http://www.smashingmagazine.com/2007/08/17/404-error-pages-reloaded/ for ideas on what you could do with a 404.

  • 1
    But there is nothing wrong with displaying the "request URI" itself - that is just what the user already has in their address bar. Aug 12, 2010 at 12:22
  • It isn't that the information itself is dangerous, but it is still information that your user sees that you didn't specifically want them to see.
    – Toby
    Aug 12, 2010 at 14:22
  • @Toby But in your answer you said they were a security risk. There isn't. And the reason many default 404 pages show the requested URI is that they redirect to another page, so the only way of knowing what you entered is if it is displayed. This helps users see if they made a typo.
    – Dan Diplo
    Aug 12, 2010 at 14:31
  • I said that any information that you don't want people to see is a security risk, which is right - you are not controlling any aspect of that user experience, and that is not safe.
    – Toby
    Aug 12, 2010 at 15:01
  • 1
    @Toby The potential risk is not from a user seeing something "you don't want people to see", as you imply, but from out-putting user input content without taking the precaution of HTML encoding it. So long as it is encoded, which is standard good practice for any content, then there isn't the slightest risk or problem showing it.
    – Dan Diplo
    Aug 12, 2010 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.