When you're exposing HTTP endpoints to others, you are expecting callers to behave as intended. Each HTTP conversation is supposed to follow a scenario that you have programmed in the service.

In the real world, that's not always the case. If the caller has a bug or is just not calling your service correctly, the expected behavior should be to send back a 4xx response and explain to the client why the request was rejected. That's also the case for malicious requests sent by attackers. Any unintended behavior should be dismissed.

The Open Web Application Security Project (OWASP) (https://www.owasp.org) is an excellent resource to learn about ways to protect your web apps from bad behaviors. They even provide a set of rules for the ModSecurity (https://modsecurity.org/crs/) toolkit's Web Application Framework (WAF) that can be used to avoid a lot of attacks.

In microservices-based applications, anything that's published to the web can be attacked, but, unlike monolithic applications, most of the system is not dealing directly with users via HTML user interfaces or public APIs, and that narrows down the spectrum of potential attacks.

We'll see in this section how to provide essential protection for our JSON-based microservices.

But before we do this, let's look at some of the most common attacks:

• SQL Injection: The attacker sends raw SQL statements in the request. If your server uses some of the request content (typically the arguments) to build SQL queries, it might perform the attacker's request on the database. In Python, though, if you use SQLAlchemy and avoid raw SQL statements altogether, you will be safe. If you use raw SQL, make sure every variable is correctly quoted. We'll see that later in this chapter.
• Cross Site Scripting (XSS): This attack happens only on web pages that display some HTML. The attacker uses some of the query attributes to try to inject their piece of HTML on the page to trick the user into performing some actions thinking they are on the legitimate website.
• Cross-Site Request Forgery (XSRF/CSRF): This attack is based on attacking a service by reusing the user's credentials from another website. The typical CSRF attack happens with POST requests. For instance, a malicious website displays a link to a user to trick that user to perform the POST request on your site using their existing credentials.

Many other attacks are specifically targeting PHP-based systems because it's widespread and easy to find a PHP app that uses invalidated user input when the server is called. Things such as ;Local File Inclusion (LFI), Remote File Inclusion (RFI), or Remote Code Execution (RCE) are all attacks that trick the server to execute something via client input or reveal server files. They can happen of course in Python applications, but Python frameworks are known to have built-in protections to avoid those attacks.

However, bad requests are not always how a client, whether it's malicious or not, can abuse your system. It can send legitimate requests and just hammer your service with it, leading to a Denial of Service (DoS) because all the resources are used to handle requests from the attacker. This problem sometimes happens within distributed systems when clients have replay features that are automatically recalling the same API. If nothing is done on the client side to throttle calls, you might end up with a service overloaded by legitimate clients.

Adding a protection on the server-side to back-off such zealous clients is usually not hard to do and goes a long way to protect your microservice stack.

In this section, we'll focus on creating a basic WAF that will explicitly reject a client that's making too many requests on our service.

We could build our WAF in a Flask microservice, but it would add a lot of overhead if all the traffic has to go through it. A much better solution is to rely directly on the web server.