- Standard and secure code
- Cross-site scripting
- Cross-browser functionality
- Minimal site performance impact
- Cross-topology and location functionality
- Data limitations
Standard and Secure Code
One of the most significant security vulnerabilities found in client-side scripting is called cross-site scripting (XSS). XSS enables attacks on web pages through the injection of client-side scripts which can then be viewed and executed by other users. This type of attack can be used, as an example, to bypass access controls on the site. Dynamically generated HTML pages are susceptible to this, unless inputs are validated either on the way in or out.
If input to a dynamic page is not validated, the following issues can result:
- Compromised data integrity
- Manipulation of cookies
- Capture of user input
- Execution of malicious scripts, as if they were from a trusted source
Cross-site scripting attacks can generally be prevented by encoding output based on input parameters, and filtering the input and output parameters for special characters. Including simple validation checks on the inputs and outputs can provide the protection that is needed against this vulnerability. Every site, page, and field must be evaluated for the cross-site scripting vulnerability.
Minimal Site Performance Impact
- Response times
- Memory consumption
Good performance is essential for a good user experience on a site. Users expect reasonable load times, smooth animation, and responsive interaction. When these are achieved, the user feels a sense of immersion in the site. If that is lost, then you’ve lost the user. For that reason, it is critical to minimize any impact on the end user experience due to performance issues.
Cross-Topology and Location Functionality
For example, if our customer is based in the US, and his customers are based in China, the script needs to run perfectly across the following:
- Countries or continents
- Communication providers
- Physical or virtual networks
There are certain data limits that must be understood when creating JS code. In order to avoid the ‘maximum request length exceeded’ type of message, we must know what those limitations are.
The difference between the maximum length of an HTTP GET request and an HTTP POST request, and when it is appropriate to substitute one for another is crucial. There are data limits both on the client and server side to consider, and each request type relies on the client or server differently.
Most web servers have a default limit of about 16Kb for HTTP GET requests, but the limit for HTTP POST is normally 2Gb. The GET request is much more reliant on the client browser, and each browser has its own limit as well. For instance, HTTP GET requests have the following limits for these browsers:
- Internet Explorer: 2Kb
- Opera: ~200Kb
- Firefox: ~100Kb
- Chrome, Safari : ~100Kb (both based on webkit)
If the limit for the HTTP GET request is exceeded in either the browser or server, then often times the extra characters will simply be truncated. Other times, you may receive an HTTP 414 error. In the case where the limit for the HTTP POST request is exceeded on the server, then an HTTP 500 error is usually the result.
We at CoolaData want our customers know that adhering to standards, understanding the importance of security, and providing for site functionality are issues that we take seriously.