Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>The reasons of not using eval</h2> <p>Well, you already said it yourself. Don't use eval. But you have a wrong picture regarding <em>why</em>.</p> <p>It is <strong>not</strong> that <strong>eval is evil</strong>. You are getting the reason wrong. Performance considerations aside, using eval this way allows a sloppy programmer to <em>execute code <strong>passed from server</strong> on the client</em>. Notice the "passed from server" part. </p> <h2>Why never execute code passed from server</h2> <p>Why don't you want to execute code passed from the server (incidentally that's what you're planning to do)?</p> <p>When a browser executes a script on a web page, as long as the web site is valid -- i.e. really yours, and not a malware site pretending to be yours trying to trick your users -- you can be reasonably sure that <em>every bit of code the browser is running is written by yourself</em>.</p> <h2>Hacker's heaven -- script injection attacks</h2> <p>Now, if you are passing data from the server to your web application, and that data contains <em>executable functions</em>, you're asking for trouble. In the long, twisted journey of that data going from your server to your client's browser, it goes through the wild west called the Internet, perhaps through multiple layers of proxies and filters and converters, most of which you do not control.</p> <p>Now, if a hacker is hiding somewhere in the middle, takes your data from the server, modify the code to those functions to something really bad, and sends it away to your client, then your client browser takes the data and executes the code. Voila! Bad things happen. The worse is: you (at the server side) will never know that your clients are hacked.</p> <p>This is called a "script injection attack" and is a <strong>serious sercurity risk</strong>.</p> <p>Therefore, the rule is: Never execute functions returned from a server.</p> <h2>Only pass data from server</h2> <p>If you only accept <em>data</em> from a server, the most that can happen whan a hacker tempers with it is that your client will see strange data coming back, and hopefully your scripts will filter them out or handle them as incorrect data. Your client's browser will not be running any <em>arbitrary code</em> written by the hacker with glee.</p> <p>In your client-side script, of course you're sticking to the Golden Rule: Do not trust ANY data coming through the Internet. Therefore you'd already be type-check and validating the JSON data before using it, and disallowing anything that looks suspicious.</p> <h2>Don't do it -- pass functions from server and execute on client</h2> <p>So, to make a long story short: <strong>DON'T DO IT</strong>.</p> <p>Think of another way to specify pluggable functionalities on the browser -- there are multiple methods.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload