Anytime a user requests something from the internet, client-to-server communication is used. The primary function of the internet is to provide the infrastructure for one computer to communicate with another computer. This exchange allows for each computer to share and exchange data.
One of those computers owns and serves the resources, which is referred to as the server-side. The other computer that requests access to those resources is referred to as the client-side. Even if a computer owns some resources, it can still be referred to as the client-side if it sends requests. Together, this method of network communication between each side is colloquially referred to as client-server architecture.
On the client-side, processes are facilitated by a computer programming language called JavaScript. Securing JavaScript is integral to deterring bad actors from intercepting sensitive information and promoting a positive user experience. Ensuring secure communication between your network and the network of client-side users should be at the top of your cybersecurity priorities list. In this guide, we will explore why securing JavaScript client-to-server communication is so important and how to do so.
Examples of Client-to-Server Communication
To best understand client-server architecture, let’s review some examples. A client is defined by the request method used to interact with the internet. The web browser you are using to access this article is a client. The web browser on your phone is a different client. Applications on your phone, computer, or gaming console are also clients. Clients are always local to the user that is requesting access, referring to the end user’s computer, phone, or other personal hardware.
A server is defined by the access method used to process requests and “serve” information to the client. Examples of server-side processes include saving and accessing data, redirection to other webpages, or user validation. Server-side processes take place at a remote location, where web application servers process web requests from the client. Those servers are centralized centers where data is stored and disseminated.
Consider anytime you go to an ATM to withdraw funds. When a customer enters their card, how does the ATM (client) interpret the digital data associated with the bank card? After the card is entered, a request for information is sent to the bank’s central software (server), which enables the ATM to display the proper data to a customer.
HTTP/HTTPS Requests
The foundation of data exchange on the internet is a client-server protocol called Hypertext Transfer Protocol (HTTP). This type of protocol means that the request-response method is used for client and web servers to communicate with each other. They communicate by exchanging individual messages. The client-sent messages are requests and messages sent by the server are called responses.
Hypertext Transfer Protocol Secure (HTTPS) is a secure version of HTTP. The primary difference between them is HTTPS uses encryption to secure communication between clients and servers. HTTPS utilizes Transport Layer Security (TLS) protocol or Secure Sockets Layer (SSL) for encryption.
Client-Side Requests
Let’s start with the initiating components of HTTP/HTTPS. The web browser, mobile browser, or user application is always the entity initiating the request. To generate a webpage, the client-side browser or API sends a request for the HTML file representing the webpage. Next, this file is analyzed, and additional requests are made for any adjacent scripts, visual sub-resources (JPG and MP4 files), and layout data (CSS). The web browser or API combines the resources from those requests and presents the complete webpage to the end-user.
A web page is a hypertext document, meaning, some parts of the page are interactive and must be triggered by an end-user action, such as clicking with a cursor/finger or inputting information to generate a new webpage. The browser or API translates these actions into HTTP requests and interprets the HTTP responses to provide the end-user with accessibility.
Server-Side Responses
On the other end of the communication chain is the server, which serves the resources requested by the client. A server may appear as a single machine, but it is likely a group of machines sharing the load, or a multi-faceted piece of software analyzing other computers completely or partially to generate the requested resources on demand.
Proxies
Between the client-side browser or API and the server, many computers, and machines relay HTTP messages. Due to the layered design of web development software, most of these operate at the physical, transport, or network levels, becoming transparent at the HTTP layer, which can significantly impact performance. Proxies are the messages that operate at the application layer. Proxies can perform many functions such as:
- Filtering – determining which requests can and can’t come through via parental controls or antivirus scans
- Authentication – controlling access to data
- Caching – storing data for later use
- Load balancing – allowing different servers to handle different requests
Client-Side JavaScript
Client-side JavaScript or CSJS is the most common type of computer language. It allows for the implementation of complex features on a web page. For the code to be interpreted by the browser to display graphics, video, link navigation, button clicks, or other complexities, the script needs to be referenced or included in an HTML document. Only when a user submits a form with complete, valid entries can the request be submitted to the web server.
Benefits of CSJS
The CSJS method allows for numerous advantages as compared to other computing languages. For instance, you can use JavaScript to confirm if the information a user has entered in a form field is valid. Other benefits of using CSJS include:
- Immediate feedback – Users don’t have to wait for a page to reload to know if they’ve forgotten to input information in a form field.
- Dynamic interfaces – Web Pages don’t have to remain static. For example, sliders can be implemented to showcase a revolving carousel of products.
- Lessened Server Load – CSJS can verify user input before sending the request to the server. In doing so, less server traffic is created.
- Amplify interactivity – CSJS allows for the creation of interfaces that react when users place their cursors over them or scroll down a webpage.
CSJS Security
JavaScript is one of the core technologies of the internet. Due to its prominence, bad actors attempt to infiltrate and distort its properties to cause harm to users on the client side. Since its release in 1995, JavaScript has had issues that have attracted the attention of the wider cybersecurity community. Most prominently, the way JavaScript interacts with the Document Object Model (DOM) presents a risk for end-users on the client side by allowing bad actors to send malicious scripts over the web to infiltrate client devices.
Two strategies can quell this JavaScript security risk:
- Sandboxing – Running scripts separately, which restricts access to resources and tasks
- Applying the same-origin policy – Stops scripts from one website from accessing data from scripts on other websites
CSJS Risks
Cross-Site Scripting (XSS) is one of the most common JavaScript security risks. In this method, hackers attempt to exploit websites to return malicious scripts to client-side users. The hacker determines what these scripts can do including spreading malware, remotely controlling an end user’s browser, stealing sensitive data, and account tampering. If the author of a browser or application neglects to implement the same-origin policy, then they have created an environment where XSS tampering can exist.
Cross-Site Request Forgery (CSRF) is another common risk with CSJS. CSRF vulnerabilities allow bad actors to deceive clients’ browsers to engage in unintentional behaviors on other sites. If a target’s site authenticates requests by only using cookies, then hackers can send requests carrying the end users’ cookies. XSS and CSRF risks live in the application layer, requiring authors to utilize the correct developmental procedures.
Many common JavaScript security issues can escalate risks for end-users, such as vulnerabilities in the browser and plug-in code, improper execution of sandboxing or same-origin policy, and faulty client-server trust relationships. The only way for authors to elude these security risks is to develop applications and browsers devoid of JavaScript security vulnerabilities from inception.
Cross-Origin Resource Sharing
As mentioned above, the implementation of a same-origin policy is a critical mechanism for controlling the permissions of a script from one web page to another. This method of securing JavaScript facilitates a secure client-to-server communication but is quite restrictive. What happens if client scripts need to access resources on another domain without the necessary access rights?
Cross-Origin Resource Sharing (CORS) is the solution. CORS is a security strategy that employs additional HTTP headers for servers to allow browsers at one origin to access resources from a different origin. CORS is essential in preventing spoofing attempts. Web applications typically have a frontend static code made up of HTML, JavaScript, CSS, and a backend API.
Bad actors can copy that static code and host it under a different domain (fake website) while using the same backend API. Next, they can employ a malicious script, sending them to that domain and utilizing a request which will provide them with page content and session cookies, this can allow them to steal login information and other sensitive information. The implementation of CORS prevents such a scenario from happening.
Domain Validation
Another strategy for securing JavaScript in client-to-server communication is to utilize a method known as domain validation. Domain Control Validation (DCV) is a strategy used by Certificate Authorities to verify that the person making a request is authorized to access the domain related to the request before providing an SSL certificate. Domain validation prevents bad actors from sending requests from fake sites and phishing attempts.
Best Practices for Client-Side Data Storage
There are many strategies for protecting sensitive data, we have covered many of them in previous articles on securing API keys and authentication. However, client-side storage enables users to log different types of data on the client with users’ permission and retrieve them later. This allows users to save web pages or documents for offline use, maintain custom settings for a website, and save data for the long term.
LocalStorage
LocalStorage allows users to store data for the entire website permanently. It is not accessible to service workers or web workers. LocalStorage can only contain strings and has a limit of 5MB. It may be useful for storing small amounts of specific storage data.
SessionStorage
SessionStorage is used to store information temporarily and cleared at the end of the webpage session. Like LocalStorage, it is not accessible to service workers or web workers because it is tab specific, has a limit of 5MB, and can only contain strings.
IndexedDB
IndexedDB is an event-based API for client-side storage for large amounts of data. This API sorts data by using keywords or listing. In many ways, IndexedDB is a bolstered version of LocalStorage. Authors can create applications with many request capacities regardless of network connectivity. This method allows application accessibility with or without a connection.
Cookies
Each new HTTP request comes with cookies, so storing data in them will bloat the size of web requests. They are synchronous and are not accessible from web workers. Just like LocalStorage and SessionStorage, cookies only contain strings.
Allow The Auth API to Secure Your Network
The Auth API takes the risk out of building a robust key store with lifecycle management and bad-actor detection. Our platform has been audited by third-party industry-leading security firms to ensure secure client-to-server communication by utilizing best practices for client-side data storage, API key security, and authentication protocols.
Secure your JavaScript client-to-server communication with The Auth API. We are a one-stop shop for your communication-secured network. Start your free trial today to learn more about our product.
