Incorporating JavaScript Secure Coding Standards and Techniques

The JavaScript language has a unique set of security challenges. When designing or writing with JavaScript, it is important to remember to provide a secure environment for executing mobile code. The Java security architecture is designed to protect systems and users from hostile programs and downloads over a network, but it cannot defend against bugs in trusted codes. This means that if trusted JavaScript code is not implemented properly, it can open holes that the platform is designed to allow. In the worst case, computers can be turned into zombie machines where confidential and sensitive data can be exposed, along with many other malicious activities.

Secure coding standards have been created to assist Java developers in creating secure code while avoiding programmer errors. These guidelines are expected to be followed under all circumstances because they ensure that the Java platform is used and implemented accurately. When the guidelines are followed, Java developers create secure end-user applications and applets that can be trusted by users.

The following are fundamental aspects of the JavaScript secure coding standards:

• Prefer to have obviously no flaws than no obvious flaws—According to the standards, it is preferred to have obviously no flaws than no obvious flaws. This means that because of how large the JavaScript language is, flaws can easily slip past even the most advanced developer. Attempt to write code that does not require clever logic to understand that it is secure. Write code that is obviously safe. it is highly recommended to follow all the JavaScript secure coding guidelines unless there is a very specific, strong reason not to.

• Avoid duplication—The next fundamental guideline is to avoid duplications. This means to avoid duplicating code and data. Duplicating causes too many problems and can lead to unexpected errors within the application. Both code and data tend not to be treated consistently when they are duplicated.

• Restrict privileges—Even with well-reviewed code, flaws may exist. Code must be operated with reduced privileges, thus deterring the ability to exploit flaws. In extreme cases, the developer can implement the principle of least privilege. The developer restricts permissions through policy files, causing the application to run in sandbox mode, unable to execute any dangerous code. The application is then safe for the user.

• Establish trust boundaries—Trust boundaries are necessary to allow easy security auditing to be performed efficiently. This means that the web browser is outside the system for the web server. Additionally, a web server should not be within the same system as the web browser, so that the security behavior of one does not affect the other.

• Contain sensitive data—Due to obvious security issues, sensitive data must be contained in a secure manner and must be kept hidden to users who lack the privilege to view it. Certain information, such as Social Security numbers and passwords, is classified as highly sensitive data. This information should not be stored and not kept for any longer than required for application purposes. Administrators should not see this information, and it should not be recorded in log files and should not be detectable through searches.

• Avoid dynamic SQL—It is a well-known security vulnerability that dynamic SQL including untrusted input is subject to SQL injection.

• XML and HTML generation require care—XXS is a common security vulnerability in many web applications. The root cause is input and output that are accepted without the input being validated. Examples can be checking for illegal characters and escaping data properly. It is better to use a library that constructs XML or HTML than to try to insert escape codes for every field in the document.

• Take care of interpreting untrusted code—Code can be hidden in many places within JavaScript. If the source is classified as untrusted, a secure sandbox must be constructed to run it. Examples that can potentially run untrusted code are scripts within scripting and allowing remote code, specified by the remote connection.