In today’s world, where everything is interconnected, the need for securing your application is paramount, and APIs are no exception. Oftentimes, APIs provide direct access to private or proprietary data. Any leak or compromise of this data can have serious consequences for both you and your users. When it comes to properly securing your API, it's best to use a defense in layers approach. The Open Systems Interconnection (OSI) model provides a conceptual framework that standardizes the functions of a computing system into seven layers. By understanding the model, and making security conscious design decisions, we can effectively minimize the vectors of attack on our API.
Network Layer (Layer 3)
Focus: DDoS Attacks, IP Spoofing, and Unauthorized Access
With most APIs being hosted on cloud infrastructure, securing the network layer is generally the lowest layer we need to worry about in the OSI model. This is because the Physical Layer (Layer 1) and Data Link Layer (Layer 2) are abstracted away and managed by the cloud service provider. What we can do at the Network Layer is control the traffic that interacts with our API. Firewalls and IP Whitelists can be configured to block unauthorized access to the network. Rate limits can be set up to mitigate the risks of DDoS attacks. In conjunction with these strategies, filtering ingress and egress data packets can help prevent IP Spoofing. A good practice is to keep your API isolated in its own Virtual Private Cloud (VPC) and only allow controlled access to it from your frontend application.
Transport Layer (Layer 4)
Focus: Man-in-the-Middle (MitM) Attacks, Eavesdropping, and Session Hijacking
The transport layer is all about ensuring data integrity, security, and authenticity when communicating data between the server and client. The first step should be to ensure the use of HTTPS over HTTP. This provides a layer of encryption on the data traffic and makes it more challenging for an attacker to eavesdrop or hijack a session. Next, we can ensure we are using the latest TLS version to minimize vulnerabilities that can be exploited by MitM attacks. Certificate Pinning can help in identifying and blocking fraudulent certificates, making it difficult for an attacker to impersonate the server.
Session Layer (Layer 5)
Focus: Session Hijacking, XSS, Cross-Site Request Forgery, and Unauthorized Access
The Session Layer plays a crucial role in establishing, maintaining, and terminating connections between applications. Implementing Session timeouts can prevent unauthorized access from compromised devices. Cookies deserve an article all on their own, but as far as securing them at the Session Layer, we can enforce Secure Cookies by using various flags like HttpOnly, Secure, and Same Site. This reduces the chances of a successful XSS and Cross-Site Request Forgery attack.
Presentation Layer (Layer 6)
Focus: Cross-Site Scripting (XSS), SQL Injection attacks, and Unauthorized Access
When it comes to our API, the Presentation Layer serves as the translation layer between the application and the transport layers. One step for securing this layer is proper data encoding & validation. One rule I first learned when I started web development was to never trust data that is inputted by a user. By sanitizing, validating, and encoding user input into a safe format we can prevent XSS and SQL Injection attacks. Limiting user access through OAuth 2.0 Authentication can also have a real impact on preventing Unauthorized Access
Your Web Application Firewall can be configured to block suspicious requests that contain SQL keywords and/or script tags. Finally, setting up a Content Security Policy (CSP) can be a useful tool to prevent XSS attacks as it allows you to specify the domains that a browser should consider as valid sources of executable scripts.
Application Layer (Layer 7)
Focus: Session Hijacking, SQL Injection, XSS, Unauthorized Access
For the grand finale, we have our application layer which is where the core of our API lives. This includes our business logic and the UI for communicating with our data. One approach to securing our API at the application layer is using a Role-Based Access Control (RBAC) approach. This restricts access based on the roles of users within an organization. In practice, this could be restricting access to functionality on your website for guests until they register an account. Data sanitization and validation was previously mentioned, but again, it is essential for preventing SQL Injection and Cross-Site Scripting (XSS) attacks. Finally, using a tool like JSON Web Tokens (JWT) can be used to prevent session hijacking by tying each session to a unique, signed token that only the server can validate.
Conclusion
As you may have realized, there are many things that can be done to lock down your API. Security is all about reducing the surface area of our application and implementing controls to minimize vulnerabilities, detect unauthorized access, and ensure data integrity and confidentiality. As proven time and time again, there is no impenetrable system out there. Part of security includes identifying a response plan and even a response team for an organization. When it comes to security, it's best to be proactive than reactive. That way, you can minimize the impact to your users, their data, and your organization.
