We know that due to numerous reasons, a browser will display a page like "Problem loading page" or "This page can’t be displayed."

But there's one huge problem: browsers seem to show this error page as if it were any regular webpage, so an attacker could replace this browser-generated one with a fake one, with buttons that link to a malicious script or page. They could simulate various error pages based on user agent, simulate a delay serving the page as if the browser was timing out, replace the favicon, and voila, an identical-looking (and malicious) error page.

How can I, as an end user, figure out that this is not a real error page and that I should not click anything because it might compromise my browser security?

  • 1
    check the address bar?
    – schroeder
    Mar 2, 2016 at 5:56
  • 2
    @schroeder From a quick check, the address bar still shows the intended url if Chrome on Android shows a "Network failure" error...
    – Matthew
    Mar 2, 2016 at 7:02
  • 2
    @Matthew sure, but think about it: if the page can be overwritten in such a way then the legitimate content could be just as malicious, which makes the question moot.
    – schroeder
    Mar 2, 2016 at 7:17

2 Answers 2


With difficulty, if you're a typical end user.

It's important to make a distinction between server generated error pages (e.g. 404 messages or similar), and browser generated pages (e.g. Network problems, server not found). Server generated pages are essentially normal web pages. They can do anything a web page can do, whilst still being an error message which may have been sent with a special error code (such as the common 404) - there is nothing special in the handling of these by browsers, if they provide content. If they don't provide content, browsers will usually give a default message rather than leave the user staring at a blank screen. You generally can't tell the difference between a server generated error page and a browser generated message in this case, unless the server sends an error page which doesn't match your browser - the only difference would be in the size of the response, which an average user may not know how to check.

Browser generated errors are more interesting in this situation. These are shown when the server cannot be contacted for some reason - network failure, mistyped domain name, that sort of thing. In this case, the page shown is generated by the browser. This is key to spotting if it is fake - browser generated content is, effectively, instant to load. It's not coming over the network, so appears as soon as the browser discovers a problem. A fake browser message would have a network delay - might not be much, but it will exist.

You could also open up the built in browser debug tools by pressing F12 and then try refreshing the page. For a genuine network issue, you shouldn't see any traffic being sent or received. For a fake one, there would be at least one connection.

However, is it worth worrying about? What could such a page do? Potentially it could serve up malware, but you wouldn't need to interact with it for that - by the time you notice, it's too late. It can't access any other browser data (cookies and local storage are subject to same origin policy, so are only available to the originating domain), and any flaw that allowed other access would work just as well on a standard page.

In short, you're probably safe to play the dinosaur jumping game on Android Chrome if it pops up!

  • This is not true for browser-generated error pages that are shown in response to a connection time out. I have had many times when the browser spends a minute or two "connecting" and then gives a client-side error page. Nov 18, 2017 at 18:12

One slightly tedious way to do it (in some browsers) is to view the page source:

  • In Chrome 40 and Firefox 44 you will get another error page and not the actual page source if the error page is legit.
  • In Internet Explorer 11 you will get the actual page source, no matter if the page is legit or not. This could easily be mimiced, so this method will not work on IE.

However, I do not see why this would be called for in ordinary situations. To serve you the false error page you must have somehow navigated to the malicious site. So why not simply serve you the malicious page at once instead? Maybe I am missing something, but I fail to see what benefit you would have from using a false error page when staging an attack.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .