There are several issues that come into play when putting sensitive data in your Javascript, such as losing SEO value or racking up development and testing costs, but the real danger is managing the sensitive information. Client-side script is accessible, or in other words, viewable. In most cases this is okay and the code will be innocuous enough, but one major problem comes in the form of authorization tasks.
Let’s first discuss the differences between client-side scripting and server-side scripting:
Client-Side Scripting
Client-side scripting is a type of program on the web that runs on the user’s computer instead of server-side. In the most basic terms, client-side can be defined to be the end user’s web browser. Client-side script is used to do processing that does not require the server to execute code such as dealing with user interactions like highlighting a row of data the user is hovering over or basic evaluations of data entered by the user or manipulation/interaction of many other HTML elements. Today there is really only one language that is used for this and it is JavaScript. However, there are several JavaScript frameworks for writing client-side code such as JQuery, Ext JS, Knockout, AngularJS and many more. In the case of client-side scripts, the code is easily visible to the end user by simply looking at the source of the code.
Server-Side Scripting
Server-side scripting can be defined to run at the origin of the program, the web server, not on the end user’s computer. When a user makes a request to a URL, code is processed on the server and HTML is delivered to the user’s browser which includes any client-side script, the program intended to run on the user’s computer. Code that executes on the server will typically do so to process the heavy lifting of the website but can also perform all of the needed processing for a web page with the use of any client-side JavaScript. It can do things like query a database, process complex computations or perform authentication/authorization and much, much more but you get the idea. Some popular server-side languages include C#, Java, Node.JS, Ruby, PHP, and Python. In the case of server-side processing, the client or the end users browser is unaware of what the server is doing. The browser simply processes the response from the server.
Additionally, client-side scripts influence the end users’ experience on a website in a way that allows for processing to happen without the need for the page to reload or refresh as it does when the server-side code executes. It is the difference between having a seamless interaction with a website or seeing the screen momentarily flicker when a request from the server is made.
Don’t Forget AJAX
There is also a middle ground: AJAX. AJAX is Asynchronous JavaScript and XML. What this does is allow for parts of a web page to be updated from the server without a full page refresh. This brings together the elegance of not seeing a flicker on the screen when requesting data from the server.
For Example…
A few times a year we get requests for sample code. A client or prospect will request a sample of JavaScript that they would like to use on their website for integrating with our services. We highly discourage this activity.
One of the ways our service works is to use our web API to make validation requests against it. To use the API, a license key is required. If the client was to use the API and integrate with JavaScript, in most cases they would run the risk of exposing their license key and allowing others to copy it and use the service beyond the original intended purpose of that client. This could lead to unexpected and unwanted transactions against the service, potentially costing the client more money than they had originally intended.
Even further, with respect to our service, we do not save details about the transactions being made. For purposes of confidentiality, we do not keep the data associated with any particular request using a license key, so it may become problematic tracking down where the unwanted transactions are coming from.
This is a simple demonstration of how using a license key in JavaScript is dangerous. However, beyond license keys, it is important that if there is any data you wish to keep secure that you do not incorporate it in client-side scripts.
How to Use JavaScript to Integrate with Service Objects’ APIs
Our recommended solution is for clients to create a web proxy as a middleman between their JavaScript and our API that stores the API license key. When their JavaScript executes it, it can gather all the details it needs, except the license key, for the operation they wish to call in our API and send that data to their web proxy. The web proxy then pulls together the data it received from the JavaScript and the license key it has stored and makes the request to our API. Our API then processes the request and sends it back to the web proxy, which in turn sends it back to the calling JavaScript.
