Malicious JavaScript: yet another reason for graceful degradation

For the many web developers out there who have been swept along by the scripting boom of the last couple of years, here is one more argument for making sure to design your scripts for graceful degradation.

The article JavaScript opens doors to browser-based attacks talks about a new kind of malicious JavaScript. I don’t know how widespread this kind of scripting is, but I would be surprised if it doesn’t become more common in the future.

Obviously there are security-minded people and companies who will provide solutions that prevent JavaScript malware from causing major damage. Some of those solutions will likely filter or block JavaScript. There will also be people who disable JavaScript to avoid being attacked.

Just take a look at the security settings in Internet Explorer. Turn it up to “High”, and boom - no more scripting. I don’t know how many people do that, but I do know that many are worried about security when they’re surfing the Web. Increasing security probably looks like a tempting option to them.

My point is that no matter how fun you have while developing your scripts, no matter how cool your client thinks your scripts are, no matter how much your scripts increase usability, you can never rely on JavaScript being available. (Unless you are developing for a closed and controlled environment, but I’m talking about websites open to the general public here.)

Keep graceful degradation in mind and you will be fine more often than not.


Posted on August 16, 2006 in JavaScript, Quicklinks


  1. A really good thing to keep in mind, especially with all the Ajax related advancements being made. Graceful degredation should be kept very close to your development process and user experiences should be enriched by JavaScript, not dependant on it.

  2. I love sites that use AJAX well - for the ‘neat’ factor. However, your statement is what hits the nail on the head - it can NEVER be trusted. I know some will argue this, just as those used to argue for flash - but the truth is WE, as developers, cannot control our users environment and settings. What about libraries or other public sectors where they may have it disabled for security purposes. We have no control over that. So, no matter what the argument - we can NEVER control client side technologies (unless, as you stated, we are in a closed environment).

    I love Javascript, and believe many useful things can be accomplished with it. Looking at Shaun Inmans site, looking at Jonathan Snooks site, looking at Justin Palmers site - they are all great sites and use JS in a degradeable manner. Unfortunately, just as with flash (which is a TOOL) - it was quickly abused.

  3. Instead of making sure our script degrade gracefully, how about we build sites and apps that work without javascript, and then simply add the JS to enhance them? I know, I know it might be a matter of semantics to some, but I feel the theory of progressive enhancement is a better recommendation than graceful degradation.

  4. How do you feel about using progressive enhancement as an alternative to graceful degradation?

  5. The mindset around progressive enhancement is a far better one than seems to surround graceful degredation.

    One starts at the beginning with full functionality then adds the unnecessary, but useful, javascript enhacements with the former, but the opposite mindset seems to be in place for the latter.

  6. August 17, 2006 by anon

    All excellent comments, but the one thing that jumped out at me in this article — if a user is truly concerned about security, IE is the last browser they should use!

    I like the notion of turning it around to enhancements (that are not critical to the page’s function). Thanks for the links in the comments…

  7. August 17, 2006 by fartikus

    i’m really amazed it has taken this long for people to realize that scripting architectures are huge exploit vectors, and not everyone on the web is your friend. first and foremost, you MUST run noscript and cookiesafe in firefox. these tools tell me amusing little things like doubleclick js trying to execute on my broker site (schwab). first of all, shame on schwab for letting third-party js run on a sensitive app. but i blocked it so no harm done (to me).

    even on the sites you choose to whitelist for cookies and js (which should be a VERY SMALL list), there is the potential for XHR and DOM exploits to execute js from third parties. the current apis must be fixed or black hats will always have tools to use.

    lastly, as mentioned above, sites should not use js unless they have to.

    this is all dark matter to the public, we still have not seen the big js exploits that are sure to come.

  8. August 17, 2006 by Roger Johansson (Author comment)

    After thinking about semantics for a bit I agree that “progressive enhancement” is a better term than “graceful degradation”, though to me they mean the same thing. Maybe “graceful degradation” is easier for hardcore scripters to digest since it makes the scripts sound slightly more important than “progressive enhancement” does ;-).

  9. A good article and some good comments here.

    I for one like the term “Progressive Enhancement” as it encapsulates a whole design philosophy geared towards web usaility: First create your structured markup and content, then add the CSS presentation layer, then add the Javascript enhancement layer.

  10. I really like that term - “Progressive Enhancement”. There’s a matter of intent regarding what term you choose. “Graceful degradation” implies that the JS is really important and that the “degraded” experience is of lesser value. “Progressive Enhancement” implies that the site is good “as is”, but is slightly improved by som JS magic.

    JS should never be used for completely new features, but rather for adding bells and whistles to the existing workflow of a site/app/whatnot.

  11. Surely the browser manufacturers should take the majority of the responsibility here. If a user sets security to high they might have trouble using such tools as interactive map services and directions which makes the Web less useful to them. If they set the security level to low then those free screensaver websites will crucify their operating system which again makes the Web less useful to them.

    Which ever way you flip it, progression or degradation, it’s a limiting aspect which increases overheads and maybe lowers functionality purely because the browsers have holes.

    When browsers tighten things up in terms of security and standards, we can all be let loose and create powerful internet applications for our clients.

  12. Thanks for this reminder. For a couple of years, I avoided javascript because of accessibility issues. Now that DOM Scripting is here, I may have let the pendulum swind too far back towards Javascript.

  13. I wish there were a way to do content negotiation based on the availability of javascript. It would make things scriptaculous ;)

  14. To me progressive enhancement and graceful degredation are the exact opposite. The progressive enhancement approach was intended as alternative to graceful degredation.

    With graceful degredation you design your page using javascript, CSS and anything else you want. You get it running in the higher capability browsers, and then proceed to check it in lesser capability browsers and tweak things as necessary to make it work. A lesser capable browser may be an older browser, a text only browser (like lynx), or a screen reader for example.

    With progressive enhancement you design your page to work with the least capable browser first, using clean semantic HTML. You then proceed to add presentation and behaviour using external CSS and javascript. The page should continue to work with lower capability browsers while users of higher capability browsers will use an enhanced interface.

    Of course no one (I know) does it purely one way of the other, most people use a mix of the two approaches. I personally think that progressive enhancement is the better approach, and I hope that the future industry trend will be in its direction.

  15. Not sure how I feel about this. On the one hand, it’s true, you cannot control the user’s environment. On the other hand, we are discovering JavaScript’s so useful that I’d be loathe to use it merely for bells and whistles.

  16. What is the most secure browser that is available right now?

  17. October 16, 2006 by Anthony

    I strongly prefer the “progressive enhancement” over the “gracefull degradation”. I’m often on a rather costly GPRS connection, so I’m really annoyed by a web-designer who fancyes that everybody who visits his site is sitting on a gigabit connection… The sites get bloated for no reason lately. I use my Opera v9 browser in the “disable all by default” mode. No plugins are allowed, referrer and cookies disabled, js is turned off, JAVA is almost never enabled at all. Even the graphics are set to “cached only”. It’s a shame how few are the sites that work correctly with me!

    My vote is for more secure and less expencive HTTP[S] (both - for us users and for web designers). Please remember - you are not *teen boys trying to prove the others that you are the “most cool web-designer ever”, who was just told about FLASH or found some intricate|cool js trick… An average web page today exceeds 100kB limit - this is awfull!!!

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.