Preventing E-Commerce Security Issues with Microservices in 2023

If you were a hacker and had the option to attack either a blog or an e-commerce site, which one would you choose? E-commerce sites handle money and sensitive consumer information, which makes e-commerce sites a prime target for security breaches and attacks.

In 2020, security incidents involving well-known e-commerce products Magneto and Spotify occurred. In one case, the use of outdated software led to the theft of credit card information. In the other, rogue employees attempted to steal customer information.

While there are many reasons why security issues in e-commerce sites can occur, in this article, you will be learning about how microservices can help to secure your e-commerce applications.

By using smaller, more composable services, you can have fine-grained control over the most important pieces of your e-commerce solution. Smaller services also can enable an organization to use a vetted and trusted third-party service for a specific piece of their business, such as taking payments or recording order details from customers, while building others in-house.

Security Threats in E-Commerce

The ways that your e-commerce application can be at risk are, for the most part, the same ways that any other software or web-based application would be at risk. This includes cross-site scripting attacks, denial of service attacks, SQL injections, man-in-the-middle attacks, and other types of attacks.

The primary difference when it comes to e-commerce applications is the value of the data they handle. Due to the high volume of private and sensitive data, like credit card information and contact details, e-commerce vendors are especially valuable targets, so they need to take all of these threat vectors even more seriously than most sites.

Before you dive into how using microservices can help to further secure your systems better, let’s look more closely at a few of these threat vectors.

Cross-site scripting attacks

Cross-site scripting attacks are when an attacker is able to insert malicious scripts into a website or application and cause the script to run on a victim’s web browser. In an e-commerce application, malicious scripts could do things like place orders on behalf of the customer, cancel orders that the customer did not want to be canceled, and access private customer information.

These kinds of security incidents can have regulatory consequences and can cause huge problems in terms of your company’s loss of reputation and trust, potentially resulting in losing customers.

In general, input sanitization, output encoding, and using content security policies are common ways of protecting against having malicious scripts on your site in the first place. Cross-Site Request Forgery (CSRF) tokens are an important protection against any malicious scripts that do manage to execute and try to make malicious HTTP requests to your site. These tokens validate to a server that a given HTML form or HTTP request is coming from in the same session that intentionally requested to view and fill the form.

Denial-of-service attacks

Often referred to as DoS attacks, these attacks are when an attacker is able to cause your software infrastructure, usually, the servers that host the software, to use an unusually large amount of system resources, thus degrading performance. This sort of attack can often cause your servers to become completely unresponsive. This can cause legitimate users to be unable to access your site, affecting your sales and potentially losing customer trust.

This type of attack can take several forms. One example is an overwhelming and massive amount of web traffic intentionally caused by a malicious actor. Another is that some systems have specific endpoints that are very resource-intensive, and a relatively small number of requests to these endpoints could cause the system performance to degrade significantly if an attacker were to take advantage of this security vulnerability.

Common solutions to these types of attacks include introducing asynchronous processing, using rate-limiting, using a content delivery network, or scaling the number of servers and resources available to your e-commerce application.

For example, resource-intensive operations that are currently computed in the same HTTP request that serves your UI could be moved, and placed in a separate process. Now your web server can send the “worker” service an asynchronous command to perform a resource-intensive operation and return to the client quickly.

If an attacker is trying to DoS attack on you, then your asynchronous messaging mechanism (e.g. RabbitMQ or Kafka) would simply have a large backlog of messages to process. After detecting the DoS attack and preventing the attacker from accessing your site, you could then temporarily create more messaging consumers to work through the backlog of messages that are waiting to be handled.

How Microservices Can Enhance Security for Your E-Commerce Application

Using microservices can offer you more flexible ways to protect against security threats. Even if you’re looking at using microservices for other reasons, it’s important to know how microservices can help you to protect your system overall. In the next part of the article, you’ll learn how to leverage microservices to protect your e-commerce applications better.

Fault isolation

One of the inherent qualities of any system made of microservices is that each service is isolated and separate from other services. Because of this compartmentalization of your services, the overall threat surface of the application is reduced.

For example, if an attacker were trying to cause a denial-of-service attack against your system, the requests would only affect the service under attack, not the application as a whole.

In a monolithic application, if an attacker manages to gain access to your database, then they potentially have access to all your data, since all data is stored in a single shared database. If you use microservices and each microservice has its own database, then a successful attacker would only gain access to one of the many databases.

As each separate microservice/database would have different credentials, this could make the initial attack less harmful overall (as a smaller portion of data is breached) and gives your organization more time to prevent the attacker from gaining access to other systems.

These benefits can also come from using a third-party service like fabric. For example, if you were building a pricing and promotion service, you could leverage fabric Offers. The result would be that DoS attacks against your pricing and promotions service would not affect your payment service.

Flexibility and infrastructure upgrade speed

By having smaller components that are owned by specific teams, each individual service can be upgraded quickly and independently. With a monolith, the entire app has to be re-tested and deployed, which can take much longer, and if there are any issues, your entire system needs to be rolled back.

Also, because the different business functions are isolated, it keeps the web of dependencies much simpler. In monolithic applications, if a third-party library needs to be updated for security reasons, it may touch many areas of the application. This means that all those areas will need to be changed and refactored. When using microservices, each service can be upgraded separately, as its team’s time frame allows.

Automated security updates and patching

When using microservices, the underlying infrastructure is usually a cloud platform. When this is the case, you can rely on the cloud service provider to manage security patching for you. In many instances, your cloud provider will automatically perform infrastructure updates and patches without you even knowing.

This is also true when you use a third-party vendor like fabric to outsource some of your services. You can rely on the service provider to keep the underlying infrastructure up to date.

Better security practices for developers

When your developers are building software using microservices, they are pushed into a position where they need to think carefully about what they do or don’t want to expose from their services. Because teams are building services that require a carefully thought-out interface, it also forces developers to explicitly consider how their API could be abused or misused.

One example of how your developers might be forced to be more thoughtful in building their software systems is when considering fault tolerance. Developers need to ask themselves the question, “What if other microservices I need to communicate with are unavailable? Can my microservices still operate normally even though other external services are not available?”

There are many techniques and patterns that can help to solve this problem, like asynchronous messaging between services, circuit breakers, and bulkheads.

Separation of the development lifecycle

If a team is working on more security-sensitive services (such as storing HIPAA-protected or other highly regulated data), that team will need a more rigorous and methodical cycle of development and release than other teams that don’t deal with such sensitive data. Staging environments can be isolated, and may need to be specialized for these services. This team is also able to move slower and more cautiously without worrying that they’re bogging down other teams.

Flexibility and focus of critical services

If building, for example, a microservice that will house very sensitive customer data, then you have the option to focus more thoroughly on security practices and testing that one specific service. In monolithic applications, this can be difficult to do, since neither the code nor the underlying infrastructure is easily isolated. Routing, server instances, and more are all shared for monoliths.

With a microservices architecture, you can use a specialized data storage technology that best solves the security issues for that specific service without affecting other teams and services. Since your services are communicating with other services via abstractions, such as APIs or asynchronous messages, the choice of data storage technology can be whatever will best fit the context.

This also applies when you decide to use third-party vendors like fabric as the engine for one of your services. They’ve already figured out what storage technology will perform optimally and be appropriately secure for the use cases of that service.

Relying on trusted and reliable vendors

With microservices, you also have the option to pass security directly to the vendor that is best equipped to handle it. For example, if you need to allow your customers to make payments, then opting to use a service like Stripe may be the best option for you. This would allow you to build the functionality of your payment service faster and with fewer security concerns because you can rely on Stripe to have secured the system appropriately.

For your product management functionality in an e-commerce application, you might choose to use fabric PIM By taking this approach, you could leverage different vendors for different purposes, levels of availability, and security.

---