The eval function is a powerful and easy way to dynamically generate code so what are the caveats?
I believe it's because it can execute any javascript function from a string. Using it makes it easier for people to inject rogue code into the application.
Its a lot harder to maintain and debug mainly. Its like a goto - you can use it, but it makes it harder to find problems and on the people how may need to make changes later.
Unless you are 100% sure that the code being evaluated is from a trusted source (usually your own application) then it's a surefire way of exposing your system to a cross-site scripting attack.
Besides the possible security issues if you are executing user-submitted code, most of the time there's a better way that doesn't involve re-parsing the code every time it's executed. Anonymous functions or object properties can replace most uses of eval and are much safer and faster.
Improper use of eval opens up your code for injection attacks
Debugging can be more challenging (no line numbers, etc.)
eval'd code executes more slowly (no opportunity to compile/cache eval'd code)
This may become more of an issue as the next generation of browsers come out with some flavor of a JavaScript compiler. Code executed via Eval may not perform as well as the rest of your JavaScript against these newer browsers. Someone should do some profiling.
Two points come to mind:
Security (but as long as you generate the string to be evaluated yourself, this might be a non-issue)
Performance: until the code to be executed is unknown, it cannot be optimized. (about javascript and performance, certainly Steve Yegge's presentation)
Unless you let eval() a dynamic content (through cgi or input) it is as safe and solid as all other JavaScript in your page.
Passing user input to eval() is a security risk, but also each invocation of eval() creates a new instance of the JavaScript interpreter. This can be a resource hog.
It is a possible security risk, it has a different scope of execution, and is quite inefficient, as it creates an entirely new scripting environment for the execution of the code. See here for some more info: http://userjs.org/help/tutorials/efficient-code#evalevil
It is quite useful, though, and used with moderation can add a lot of good functionality.
It greatly reduces your level of confidence about security.
It's not necessarily that bad provided you know what context you're using it in.
If your application is using eval() to create an object from some JSON which has come back from an XMLHttpRequest to your own site, created by your trusted server-side code, it's probably not a problem.
Untrusted client-side Javascript can't do that much anyway. Provided the thing you're eval'ing has come from a reasonable source, you're fine.
eval isn't always evil. There are times where it's perfectly appropriate.
However, eval is currently and historically massively over-used by people who don't know what they're doing. That includes people writing JavaScript tutorials, unfortunately, and in some cases this can indeed have security consequences - or, more often, simple bugs. So the more we can do to throw a question mark over eval, the better. Any time you use eval you need to sanity-check what you're doing, because chances are you could be doing it a better, safer, cleaner way.
To give an all-too-typical example, to set the colour of an element with an id stored in the variable 'potato':
eval('document.'+potato+'.style.color= "red"');
If the authors of the kind of code above had a clue about the basics of how JavaScript objects work, they'd have realised that square brackets can be used instead of literal dot-names, obviating the need for eval:
document[potato].style.color= 'red';
...which is much easier to read as well as less potentially buggy.
(But then, someone who /really/ knew what they were doing would say:
document.getElementById(potato).style.color= 'red';
which is more reliable than the dodgy old trick of accessing DOM elements straight out of the document object.)
one thing to keep in mind is that you can often use eval() to execute code in an otherwise restricted environment - social networking sites that block specific javascript functions can sometimes be fooled by breaking them up in an eval block -
eval('al' + 'er' + 't(' + 'hi there!' + ')');
So if you're looking to run some javascript where it might not otherwise be allowed (myspace, i'm lookin' at you...) then eval() can be a useful trick.
However, for all the reasons mentioned above, you shouldn't use it for your own code, where you have complete control - it's just not necessary, and better-off relegated to the 'tricky js hax' shelf.
hie, i am also using eval but i face an issue in firefox, actually i am using it something like this
var evalCode = function(code) {
alert(code);
if (window.execScript) window.execScript(code);
else eval(unescape(code));
eval(code);
//alert("code executed..");
};
function ShowUploadPopUp() {
//alert("OK.");
evalCode(document.getElementById("JScriptCall").innerHTML);
}
where JScriptCall is span element in which i write the following lines from code behind using C# with ASP.Net
<span id="JScriptCall" class="DisplayNone">
window.open('test.aspx?uid=MzU5-OlWfO7Q3&catid=NDUGM67ISI', 'page', 'toolbar=0, scrollbars=1, location=0, statusbar=0, menubar=0, resizable=0, width=600, height=410, left=50, top=50, titlebar=yes');
</span>
but when i use it in firefox, it opens the window but the url created is not right. it convets '&' to '& amp;' (without space) because of which i can not get the values of the querystring....
any help, how can i keep ascii charaters in the querystring using eval function...
If you are wanting the user to input some logical functions and evaluate for AND the OR then the javascript eval function is perfect. I can accept two strings and eval(uate) string1 === string2 etc
Ian