Cloud

Today, we are thrilled to announce the general availability of C4A virtual machines with Titanium SSDs custom designed by Google for cloud workloads that require real-time data processing, with low-latency and high-throughput storage performance. Titanium SSDs on C4A VMs deliver storage performance of up to 2.4M random read IOPS, up to 10.4 GiB/s of read throughput, and up to 35% lower access latency compared to previous generation SSDs.¹

Titanium SSDs enhance storage security and performance while offloading local storage processing to free up CPU resources. Titanium SSDs are the first generation of Google SSDs integrated with Titanium, a system that boosts application performance by offloading networking, storage and management from the host CPU into a system of custom silicon, hardware and software on-host and throughout our data centers, connected to the host CPU using a Titanium Offload Processor. 

C4A is a VM instance family, based on Google Axion Processors, that provides up to 65% better price-performance and up to 60% better energy efficiency than comparable current-generation x86-based instances². Together, C4A and Titanium SSDs deliver industry-leading price-performance for a broad range of Arm-compatible general-purpose workloads such as high-performance databases, analytics engines, and search and workloads that benefit from caching and local storage capacity.

C4A with Titanium SSDs offer up to 72 vCPUs, 576 GB of memory, and 6 TB of local storage in two shapes — Standard (with 4 GB of memory per vCPU) and High-memory (with 8 GB of memory per vCPU). C4A delivers the connectivity and storage performance that enterprise workloads need with up to 50 Gbps in standard bandwidth and up to 100 Gbps with Tier1 networking for high-traffic applications. C4A instances also support Google Cloud’s latest-generation Balanced and Extreme Hyperdisk storage for scalable, high-performance storage with up to 350k IOPS and 5 GB/s throughput per VM. 

Google Cloud customers can use C4A with Titanium SSD in Compute Engine, Google Kubernetes Engine (GKE), Batch, and Dataproc, and more. C4A VMs are also now available in preview in Dataflow, with support for Cloud SQL, AlloyDB, with other services coming soon.

What our customers and partners are saying

“Couchbase Capella Columnar is purpose-built to accelerate complex analytical queries for real-time insights and empower AI-driven applications. Capella Columnar, running on Google Axion C4A instances with Titanium SSDs, delivers unparalleled price-performance, ultra-low latency and scalable compute power for analytic and operational workloads. We look forward to helping organizations deliver premium customer experiences with Capella Columnar on Google Axion processors.” – Matt McDonough, SVP of Product and Partners, Couchbase

“We are excited to introduce Axion-based C4A VMs with Titanium SSDs to Databricks on Google Cloud in the coming weeks, enabling us to deliver ever stronger price-performance and efficiency gains for our customers. The optimizations offered by Google’s latest Axion compute and Hyperdisk storage options will help customers generate more value from their data warehousing and AI investments on the Databricks Data Intelligence Platform.” – Abhishek Rai, Sr. Director of Engineering, Databricks

“Elastic is committed to enabling customers to drive innovation and cost-efficiency with our Search, AI-powered observability, security, and search solutions on Google Cloud. Google Axion-based C4A VMs with Titanium SSDs provided up to 40% better throughput compared to previous generation VMs in our testing. We look forward to introducing Google Cloud C4A VMs with local Titanium SSD on Elastic Cloud.” – Uri Cohen, VP of Product Management, Elastic

Try C4A now

C4A instances are now generally available via on-demand, Spot VMs, reservations, committed use discounts (CUDs), and FlexCUDs. C4A VMs with Titanium SSDs are available in us-central1 (Iowa), us-east4 (Virginia), us-east1 (SC), europe-west1 (Belgium), europe-west4 (Netherlands), europe-west3 (Frankfurt), europe-west2 (London) and asia-southeast1 (Singapore) today, with availability in additional regions coming soon. Get started on C4A with Titanium SSD today g.co/cloud/axion.

<sup>1. Results are based on Google Cloud’s internal benchmarking
2. As of September 2024, based on published listed prices. Performance based on the estimated SPECrate®2017_int_base performance benchmark scores run in production on comparable latest-generation generally-available VMs with general purpose storage types.</sup>

Bitly’s partnership with Google Web Risk helps enhance Bitly’s ability to protect users and build trust as they generate millions of links and QR Codes daily. 

Over the last decade, Bitly has solidified its reputation as a multiproduct connections platform, generating millions of links, QR codes, and mobile landing pages every day. Bitly enables users to shorten and customize long URLs for easier sharing, management, and tracking. Its capabilities in link tracking and analytics make Bitly a powerful and essential tool for brands and businesses of all sizes. As the company continues to scale, it’s constantly exploring new ways to enhance its trust and safety program. 

Bitly’s trust and safety principles

Bitly’s commitment to trust and safety unfolds in a three-pronged approach. First, the company uses its proprietary technology, including the Bitly Abuse Prevention System and its Threat Detection Service (TDS) and Abuse API, to monitor and remove harmful URLs, ensuring a safer online experience for all users. 

Next, Bitly supports its users by fostering innovation, upholding core values, enforcing an Acceptable User Policy (AUP), and developing user-friendly tools including the Bitly Trust Center.  

Finally, Bitly forges partnerships with technology experts and NGOs to combat online threats such as terrorism, child sexual abuse materials (CSAM), and phishing campaigns, including its partnership with Google Web Risk.

Google Web Risk and Bitly

To strengthen its already robust trust and safety program, Bitly partnered with Google Web Risk to evaluate linked URLs in real-time against Google’s consistently updated database of unsafe web resources and URLs that violate any of the company’s Safe Browsing policies. Web Risk includes data on more than 1 million unsafe URLs, and continually updates this information by analyzing billions of URLs daily. These unsafe URLs typically include social engineering sites — such as phishing and deceptive sites — and sites that host malware or unwanted software. 

“Our goal is to keep users safe and earn their trust by leveraging Google Web Risk’s enterprise security service to validate the safety of millions of generated links and QR Codes in real-time. Given the scale and speed of our users generating millions of links each day, Google Web Risk’s ability to handle this type of volume while delivering real-time verdicts is crucial to ensure seamless and safe online experiences,” said Ben Kleiman, director of Trust and Safety, Bitly.  

Some of the key features that Bitly and Google Web Risk bring to customers include:

• Checking millions of links and QR codes automatically every day, in real-time, for signals of abusive or malicious content.

• Delivering high-fidelity confidence scoring for near real-time automatic, programmatic blocking, or warnings of abusive content.

• Providing actionable insights on common types of abusive content such as phishing, malware, spam, and other threats targeting users.

• Surfacing patterns of abuse that point to bad actors for strategic response.

• Strengthening the competitive advantage around brand trust in the safety of Bitly links.

Web Risk confidence scoring avoids false positives

One key area of content safety that can be the trickiest for companies is the calibration of confidence scoring to avoid false positives in threat detection for URLs. 

Google Web Risk’s enterprise-grade features include risk scoring and confidence levels, a unique capability that interested Bitly and added value to the partnership. Web Risk’s confidence scoring helps organizations evaluate the maliciousness level of a URL based on blocklists, machine learning models, and heuristic rules. Web Risk ranks URLs as low, medium, high, very high, and extremely high risk. 

“We put a significant focus on confidence scoring within Web Risk to maintain customer trust,” said Kleiman. “Failing to block a malicious URL can undermine that trust, just as false positives can hurt user confidence in our links. We meticulously calibrate confidence scoring with Web Risk and have fine-tuned our threshold where our false positive rate has been remarkably low, particularly given the scale of links and QR codes we generate daily.”

Bitly continues to evolve its security stack to protect its users

Navigating the constantly shifting Internet environment proves to be a challenge for every technology company. Bitly recognizes the importance of adopting cutting-edge technology to safeguard its users effectively. 

Bitly has a unique vantage point on the Internet since it captures a lot of signals from many different users in many different industries. 

“Our goal is to enhance our security infrastructure to make smarter, faster, and more impactful decisions – not just around websites, but also around our users and their associated accounts. Web Risk is now a core part of this effort, and we are looking forward to leveraging more Google resources, like reCAPTCHA, which will be the next big thing to enhance Bitly’s capabilities,” said Kleiman.

As Bitly’s product offerings grow, so does the complexity of the threat landscape faced by the company’s Trust and Safety team. Kleiman said, “As we continue to evolve, Google’s suite of solutions can provide the necessary tools we need to address our evolving needs so that we can stay ahead of the curve.”

The last few weeks of 2024 were exhilarating as we worked to bring you multiple advancements in AI infrastructure, including the general availability of Trillium, our sixth-generation TPU, A3 Ultra VMs powered by NVIDIA H200 GPUs, support for up to 65,000 nodes in Google Kubernetes Engine (GKE), and Parallelstore, our distributed file system service that offers low-latency, high-throughput storage that’s essential for HPC and AI workloads. We’re excited to see what you build with these new capabilities.

These innovations come together in AI Hypercomputer, a systems-level approach that draws from our years of experience serving AI experiences for billions of users, and combines performance-optimized hardware, open software and frameworks, and flexible consumption models. This means when you build your AI solution on Google Cloud, you can choose from a set of purpose-built infrastructure components that are designed to work well together. This freedom to choose the appropriate solution for the needs of your specific workload is fundamental to our approach.

Here are some key updates to AI Hypercomputer from the last quarter based on new infrastructure components and how they enable specific AI use cases.

Running distributed (multi-node) workloads

The performance of multi-node (multi-host) applications such as large-scale AI training and HPC workloads can be highly sensitive to network connectivity, requiring precise setup and proactive monitoring. We wanted to make it easier for customers to run large multi-node workloads on GPUs, and launched A3 Ultra VMs and Hypercompute Cluster, our new highly scalable clustering system. Both offerings were made generally available to close out 2024.   

A3 Ultra, with NVIDIA H200 GPUs is a new addition to the A3 family of NVIDIA Hopper GPU-accelerated VMs with twice the GPU-to-GPU network bandwidth and twice the high bandwidth memory (HBM) compared to A3 Mega with NVIDIA H100 GPUs. A3 Ultra VMs offer the best performance in the A3 family. They are built with our new Titanium ML network adapter and incorporate NVIDIA ConnectX-7 network interface cards (NICs) to deliver a secure, high-performance cloud experience for AI workloads. Combined with our datacenter-wide 4-way rail-aligned network, A3 Ultra VMs deliver up to 3.2 Tbps of non-blocking GPU-to-GPU communication with RDMA over Converged Ethernet (RoCE). 

A3 Ultra VMs are also available through GKE, which provides an open, portable, extensible, and highly scalable platform for training and serving AI workloads. To try out A3 Ultra VMs, you can easily create a cluster with GKE or try this pretraining GPU recipe.

Hypercompute Cluster, meanwhile, is a supercomputing services platform built on AI Hypercomputer that lets you deploy and manage a large number of accelerators as a single unit. With features such as dense co-location of resources with ultra-low-latency networking, targeted workload placement, advanced maintenance controls to minimize workload disruption, and topology-aware scheduling integrated into popular schedulers like Slurm and GKE, we built Hypercompute Cluster to help you achieve your throughput and resilience goals. You can use a single API call with pre-configured and validated templates for reliable and repeatable deployments, and with cluster-level observability, health monitoring, and diagnostic tooling, Hypercompute Clusters can run your most demanding workloads easily on Google Cloud. Hypercompute Cluster is now available with A3 Ultra VMs.

LG Research is an active user of Google Cloud infrastructure, which they used to train their large language model, Exaone 3.0. They are also an early adopter of A3 Ultra VMs and Hypercompute Cluster, which they are using to power their next set of innovations. 

“From the moment we started using Google Cloud’s A3 Ultra with Hypercompute Cluster, powered by NVIDIA H200 GPUs, we were immediately struck by its remarkable performance gains and seamless scalability for our AI workloads. Even more impressive, we had our cluster up and running with our code in under a day — an enormous improvement from the 10 days it used to take us. We look forward to further exploring the potential of this advanced infrastructure for our AI initiatives.” – Jiyeon Jung, AI Infra Sr Engineer, LG AI Research

Making inference on TPUs easier

To enable the next generation of AI agents capable of complex, multi-step reasoning, you need accelerators designed to handle the demanding computational requirements of these advanced models. Trillium TPUs provide significant advancements for inference workloads, delivering up to 3x improvement in inference throughput compared to prior generation TPU v5e. 

There are multiple ways to leverage Google Cloud TPUs for AI inference based on your specific needs. You can do this through Vertex AI, our fully managed, unified AI development platform for building and using generative AI, and which is powered by the AI Hypercomputer architecture under the hood. But if you need greater control, we have options lower in the stack that are designed for optimal serving on Cloud TPUs: JetStream is a memory-and-throughput-optimized serving engine for LLMs. MaxDiffusion offers a launching point for diffusion models. And for the Hugging Face community, we worked closely with Hugging Face to launch Optimum TPU and Hugging Face TGI to make serving on Cloud TPUs easier. 

Most recently, we announced experimental support for vLLM on TPU with PyTorch/XLA 2.5. Motivated by the great response for this popular serving option, we’ve been running a preview with a small set of customers to get to the stage of bringing the performance (and price-performance) benefits of Cloud TPUs to vLLM.

Our goal is to make it easy for you to try out Cloud TPUs with your existing vLLM setup — just make a few configuration changes to see performance and efficiency benefits in Compute Engine, GKE, Vertex AI, and Dataflow. You can take vLLM for a spin on the Trillium TPUs with this tutorial. All this innovation is happening in the open, and we welcome your contributions. 

And in case you missed it, Google Colab now supports Cloud TPUs (TPU v5e) if you want to try TPUs for your project.

Pushing the boundaries of AI infrastructure

As we start a new year, we’re excited to continue pushing the boundaries of AI infrastructure with AI Hypercomputer. These updates represent our ongoing commitment to providing you with the performance, efficiency, and ease of use you need to accelerate your AI journey. We look forward to seeing what you achieve with these new capabilities.

In many industries including finance and healthcare, sensitive data such as payment card numbers and government identification numbers need to be secured before they can be used and shared. A common approach is applying tokenization to enhance security and manage risk.

A token is a substitute value that replaces sensitive data during its use or processing. Instead of directly working with the original, sensitive information (usually referred to as the “raw data”), a token acts as a stand-in. Unlike raw data, the token is a scrambled or encrypted value. 

Using tokens reduces the real-world risk posed by using the raw data, while maintaining the ability to join or aggregate values across multiple datasets. This technique is known as preserving referential integrity.

Tokenization engineered into Google Cloud

While tokenization is often seen as a specialized technology that can be challenging and potentially expensive to integrate into existing systems and workflows, Google Cloud offers powerful, scalable tokenization capabilities as part of our Sensitive Data Protection service. With it, you can make calls into serverless API endpoints to tokenize data on the fly in your own applications and data pipelines. 

This allows you to enable tokenization without needing to manage any third-party deployments, hardware, or virtual machines. Additionally, the service is fully regionalized, which means tokenization processing happens in the geographical region of your choice helping you to adhere to regulatory or compliance regimes. The pricing is based on data-throughput with no upfront costs, so you can scale to meet the needs of your business with as little or as much as you need. 

Sensitive Data Protection takes things even further offering in-line tokenization for unstructured, natural language content. This allows you to tokenize data in the middle of a sentence and if you pick two-way tokenization (and have the right access permissions), you can even detokenize data back when necessary. 

This opens up a whole new set of use-cases including run time tokenization of logs, customer chats, or even as part of a generative AI-serving framework. We’ve also built this technology directly into Contact Center AI and Dialogflow services so that you can tokenize customer engagement on-the-fly.

Tokenization with BigQuery

In addition to serverless access through Sensitive Data Protection, we also offer tokenization directly in BigQuery. This gives you tokenization methods at your fingertips in BigQuery SQL queries, User Defined Functions (UDFs), views, and pipelines. 

Tokenization technology is built directly into the BigQuery engine to work at high speed and high scale for structured data, such as tokenizing an entire column of values. The resulting tokens are compatible and interoperable with those generated through our Sensitive Data Protection engine. That means you can tokenize or detokenize in either system without incurring unnecessary latency or costs, all while maintaining the same referential integrity. 

Using tokens to solve real problems

While the token obfuscates the risk, utility and value are still preserved. Consider the following table which has four rows and three unique values: value1, value2, value3. 

<value1> → <token1>
<value2> → <token2>
<value1> → <token1>
<value3> → <token3>

Here you can see that each value is replaced with a token. Notice how “value1” gets “token1” consistently. If you run an aggregation and count unique tokens, you’ll get a count of three, just like on the original value. If you were to join on the tokenized values, you’d get the same type of joins as if joining on the original value. 

This simple approach unlocks a lot of use cases.    

Obfuscating real-world risk

Consider the use-case of running fraud analysis across 10 million user accounts. In this case, let’s say that all of your transactions are linked to the end-users email address. An email address is an identifier that poses several risks:

• It can be used to contact the end-user who owns that email address.

• It may link to data in other systems that are not supposed to be joined.

• It may identify someone’s real world identity and risk exploding that identity’s connection to internal data.

• It may leak other forms of identity, such as the name of the owner of the email account.

Let’s say that the token for that email is “EMAIL(44):AYCLw6BhB0QvauFE5ZPC86Jbn59VogYtTrE7w+rdArLr” and this token has been scoped only to the tables and dataset need for fraud analysis. That token can now be used in place of that email address and you can tokenize the emails across all the transaction tables, and then run fraud analysis. 

During this analysis any users or pipelines exposed to the data would only see the obfuscated emails, thus protecting your 10 million users while unblocking your business.

Next steps

Tokenization provides a powerful way to protect sensitive information while still allowing for essential data operations. By replacing sensitive data with non-sensitive substitutes, tokens can significantly reduce the risk of data breaches and simplify compliance efforts. Google Cloud simplifies tokenization by offering a readily available, scalable, and region-aware service, allowing you to focus on your core business rather than managing infrastructure. 

To get started on using tokenization on Google Cloud, see the following:

• Sensitive Data Protection Tokenization and pseudonymization

• Learn more about BigQuery Encrypt and Decrypt compatibility with Sensitive Data Protection

Written by: Steven Karschnia, Truman Brown, Jacob Paullus, Daniel McNamara

Executive Summary

• Due to their client-side nature, single-page applications (SPAs) will typically have multiple access control vulnerabilities

• By implementing a robust access control policy on supporting APIs, the risks associated with client-side rendering can be largely mitigated

• Using server-side rendering within the SPA can prevent unauthorized users from modifying or even viewing pages and data that they are not authorized to see

Introduction

Single-page applications (SPAs) are popular due to their dynamic and user-friendly interfaces, but they can also introduce security risks. The client-side rendering frequently implemented in SPAs can make them vulnerable to unauthorized access and data manipulation. This blog post will explore the vulnerabilities inherent in SPAs, including routing manipulation, hidden element exposure, and JavaScript debugging, as well as provide recommendations on how to mitigate these risks.

Single-Page Applications

A SPA is a web application design framework in which the application returns a single document whose content is hidden, displayed, or otherwise modified by JavaScript. This differs from the flat file application framework traditionally implemented in PHP or strictly HTML sites and from the Model-View-Controller (MVC) architecture where data, views, and server controls are handled by different portions of the application. Dynamic data in SPAs is updated through API calls, eliminating the need for page refreshes or navigation to different URLs. This approach makes SPAs feel more like native applications, offering a seamless user experience. JavaScript frameworks that are commonly used to implement SPAs include React, Angular, and Vue.

Client-Side Rendering

In SPAs that use client-side rendering, a server responds to a request with an HTML document that contains only CSS, metadata, and JavaScript. The initially returned HTML document does not contain any content, and instead once the JavaScript files have been run in the browser, the application’s frontend user interface (UI) and content is loaded into the HTML document at runtime. If the application is designed to use routing, JavaScript takes the URL and attempts to generate the page that the user requested. While this is happening, the application is making requests to the API endpoint to load data and check whether or not the current user is authorized to access the data. If a user is not yet authenticated, then the application will render a login page or redirect the user to a separate single sign-on (SSO) application for authentication.

While all of this happens, a user may briefly observe a blank white page before the application dashboard or login page is loaded into their browser. During this pause, the application is potentially loading hundreds of thousands of lines of minified JavaScript that will build the full user experience of the application. SPAs are used in millions of applications across the globe, including Netflix, Hulu, Uber, and DoorDash.

Issues with Client-Side Rendering

Because SPAs rely entirely on the client’s browser to render content (using API data), users have significant control over the application. This enables users to manipulate the application freely, making user or role impersonation easier.

Routing

One fundamental aspect of the JavaScript frameworks that SPAs are implemented in is the idea of routes. These frameworks use routes to indicate different pages in the application. Routes in this case are different views that a user can see, like a dashboard or user profile. Since all of the JavaScript is handled by the client’s browser, the client can view these routes in the JavaScript files that are included in the application source. If a user can identify these routes, they can attempt to access any of them. Depending on how the JavaScript was implemented, there may be checks in place to see if a user has access to the specific route. The following is an example of React routing that includes information on creating the views, and more importantly path attributes.

In = function () {
	return (0, _.jsx)(d.rs, {
		children: (0, _.jsxs)(ki, {
			children: [
			(0, _.jsx)(d.AW, {
				path: "/dashboard",
				children: (0, _.jsx)(Ii, {}),
			}),
			(0, _.jsx)(d.AW, {
				path: "/users",
				children: (0, _.jsx)(wi, {}),
			}),
			(0, _.jsx)(d.AW, {
				path: "/profile",
				children: (0, _.jsx)(Ti, {}),
			}),
			],
		}),
	});
};

Hidden Elements

One way that access control is handled by SPAs is through hidden page elements. This means that when the page loads, the application checks the user’s role through local/session storage, cookie values, or server responses. After the application checks the user’s role, it then displays or hides elements based on the user’s role. In some cases, the application only renders elements that are accessible by the user. In other cases, the application renders every element but “hides” them by controlling the CSS properties of the element. Hidden elements can be exposed through browser Developer Tools, allowing users to force their display. These hidden elements could be form fields or even links to other pages.

JavaScript Debugging

Modern browsers allow users to debug JavaScript in real time with breakpoints. Modern web browsers allow breakpoints to be set on JavaScript files, which can be used to modify variables or rewrite functions all together. Debugging core functions can allow users to bypass access controls and gain unauthorized page access. Consider the following JavaScript:

function isAuth() {
        var user;
        var cookies = document.cookies;
        var userData = btoa(cookies).split(‘:’);
        if (userData.length == 3) {
                user.name = userData[0];
                user.role = userData[1];
                user.isAuthed = userData[2]; 
        } else {
                user.name = “”;
                user.role = “”;
                user.isAuthed = false; 
        }
        return user;
}

The previously defined function reads a user’s cookie, Base64 decodes the value, splits the text using : as the delimiter, and if the values match, it considers the user as authenticated. Identifying these core functions allows an attacker to bypass any authorization and access controls that are being handled by the client-side application.

Exploitation

Manually exploiting JavaScript framework issues takes time and practice, but there are a few techniques that can make it easier. A common technique involves analyzing JavaScript files to identify application routes. Identifying routes allows you to “force-browse” to application pages and access them directly, rather than through the UI. This technique may work on its own, but other times you may need to identify any role checks in the application. These checks can be accessed through the JavaScript debugger to modify variables during execution to bypass authorization or authentication checks. Another useful technique involves capturing server responses to requests for user information in an HTTP proxy, such as Burp Suite Professional, and manually modifying the user object. While these exploitation techniques are effective, they can be mitigated through strong preventative measures, including those detailed in this post.

Recommendations

Access control issues are systemic to client-side-rendered JavaScript frameworks. Once a user has the application loaded into their browser, there are few effective mitigations to prevent the user from interacting with content in unauthorized ways. However, by implementing robust server-side access control checks on APIs, the effect that an attacker could produce is severely reduced. While the attacker might be able to view what a page would look like in the context of an administrator or even view the structure of a privileged request, the attacker would be unable to obtain or modify restricted data. 

API requests should be logged and monitored to identify if unauthorized users are attempting to or successfully accessing protected data. Additionally, it is advisable to conduct periodic penetration tests of web applications and APIs throughout their lifetime to identify any gaps in security. Penetration testing should uncover any APIs with partial or incomplete access control implementations, which would provide an opportunity to remediate flaws before they are abused by an adversary.

API Access Controls

Implementing robust API access controls is critical for securing SPAs. Access control mechanisms should use a JSON Web Token (JWT) or other unique, immutable session identifier to prevent users from modifying or forging session tokens. API endpoints should validate session tokens and enforce role-based access for every interaction. APIs are often configured to check if a user is authenticated, but they don’t comprehensively check user role access to an endpoint. In some cases, just one misconfigured endpoint is all it takes to compromise an application. For example, if all application endpoints are checking a user’s role except the admin endpoint that creates new users, then an attacker can create users at arbitrary role levels, including admin users. 

An example of proper API access control is shown in Figure 1.

This diagram shows a user authenticating to the application, receiving a JWT, and rendering a page. The user interacts with the SPA and requests a page. The SPA identifies that the user is not authenticated so the JavaScript renders the login page. Once a user submits the login request, the SPA forwards it to the server through an API request. The API responds stating the user is authenticated and provides a JWT that can be used with subsequent requests. Once the SPA receives the response from the server, it stores the JWT and renders the dashboard that the user originally requested. 

At the same time, the SPA requests the data necessary to render the page from the API. The API sends the data back to the application, and it is displayed to the user. Next, the user finds a way to bypass the client-side access controls and requests the main admin page in the application. The SPA makes the API requests to render the data for the admin page. The backend server checks the user’s role level, but since the user is not an admin user, the server returns a 403 error stating that the user is not allowed to access the data.

The example in Figure 1 shows how API access controls prevent a user from accessing API data. As stated in the example, the user was able to access the page in the SPA; however, due to the API access controls, they are not able to access the data necessary to fully render the page. For APIs developed in C# or Java, frameworks often provide annotations to simplify implementing access controls.

Server-Side Rendering

Aside from API access controls, another way to mitigate this issue is by using a JavaScript framework that has server-side rendering capabilities, such as Svelte-Kit, Next.js, Nuxt.js, or Gatsby. Server-side rendering is a combination of the MVC and SPA architectures. Instead of delivering all source content at once, the server renders the requested SPA page and sends only the finalized output to the user. The client browser is no longer in charge of routing, rendering, or access controls. The server can enforce access control rules before rendering the HTML, ensuring only authorized users see specific components or data.

An example of server-side rendering is shown in Figure 2.

This diagram shows a user accessing a server-side rendered application. After requesting an authenticated page in the application, the server checks if the user is authenticated and authorized to view the page. Since the user is not yet authenticated, the application renders the login page and displays that page to the user. The user then authenticates, and the server builds out the session, sets necessary cookies or tokens, and then redirects the user to the application dashboard. Upon being redirected, the user makes a request, the server checks the authentication state, and since the user has permissions to access the page, it fetches the necessary data and renders the dashboard with the data. 

Next, the user identifies an admin page URL and attempts to access it. In this instance, the application checks the authentication state and the user’s role. Since the user does not have the admin role, they are not allowed to view the page and the server responds with either a 403 Forbidden or a redirection to an error page.

A Final Word

In conclusion, SPAs offer a dynamic and engaging user experience, but they also introduce unique security challenges when implemented with client-side rendering. By understanding the vulnerabilities inherent in SPAs, such as routing manipulation, hidden element exposure, and JavaScript debugging, developers can take proactive steps to mitigate risks. Implementing robust server-side access controls, API security measures, and server-side rendering are excellent ways to safeguard SPAs against unauthorized access and data breaches. Regular penetration testing and security assessments can further strengthen the overall security posture of SPAs by identifying any security gaps present in the application and allowing developers to remediate them before they are exploited. By prioritizing security best practices, developers can ensure that SPAs deliver both a seamless user experience and a secure environment for sensitive data.