, we listed and described how to implement them with Apache APISIX. Last week 16 practices to help secure one's APIs Authentication 🕵️️ - Verifies the identity of users accessing APIs. Authorization 🚦 - Determines permissions of authenticated users. Data Redaction 🖍️ - Obscures sensitive data for protection. Encryption 🔒 - Encodes data so only authorized parties can decode it. Error Handling ❌ - Manages responses when things go wrong, avoiding revealing sensitive info. Input Validation & Data Sanitization 🧹 - Checks input data and removes harmful parts. Intrusion Detection Systems 👀 - Monitor networks for suspicious activities. IP Whitelisting 📝 - Permits API access only from trusted IP addresses. Logging and Monitoring 🖥️ - Keeps detailed logs and regularly monitors APIs. Rate Limiting ⏱️ - Limits user requests to prevent overload. Secure Dependencies 📦 - Ensures third-party code is free from vulnerabilities. Security Headers 📋 - Enhances site security against types of attacks like XSS. Token Expiry ⏳ - Regularly expiring and renewing tokens prevents unauthorized access. Use of Security Standards and Frameworks 📘 - Guides your API security strategy. Web Application Firewall 🔥 - Protects your site from HTTP-specific attacks. API Versioning 🔄 - Maintains different versions of your API for seamless updates. This week, we will look at the remaining practices. Encryption and Data Redaction First, we must protect the communication channel between our APIs and clients from unwanted reads and writes. That's the realm of TLS. In this regard, mutual TLS is state-of-the-art. Please read this about mTLS in Apache APISIX. previous post I can't guess what the author meant by "Obscures sensitive data for protection". If data exchanges are encrypted, it doesn't make sense to obfuscate any payload. Error Handling The list mentions avoiding revealing sensitive info when an error happens. Indeed, some poorly coded upstreams can disclose such data. Here's an example of Tomcat when developers forgot to configure an error page. It reveals the upstream's technology, version, and the guilty code. Apache APISIX can intercept such a response and rewrite it: routes:
  - upstream_id: 1
    plugins:
      response-rewrite:
        vars: [[ "status","==",500 ]]                        #1
        body: { "error" : "An unknown exception happened"}   #2 Triggered only in case of HTTP status code 500 returned by the upstream. You can add additional status codes if necessary. The body to return To make sure the above configuration is applied consistently, we can also make it a global rule: global_rules:
  - id: 1
    plugins:
      response-rewrite:
        vars: [[ "status","==",500 ]]
        body: { "error" : "An unknown exception happened"} Security Headers The OWASP lists plenty of you can set to improve the security of your web apps and APIs. Apache APISIX provides two dedicated plugins for specific security risks: HTTP Headers CORS CSRF For any other header, you can use the more generic plugin to add them. response-rewrite Finally, we can remove default HTTP response headers, such as , to make targeted attacks less likely. Server global_rules:                               #1
  - id: 1
    plugins:
      response-rewrite:
        headers:
          set:
            X-Content-Type-Options: nosniff #2
          remove:
            - Server                        #3 Do on every route - security by default! It still can be overridden on a per-route basis, in case of need Tell the browser not to infer the content type if it's not explicitly set Don't advertise the server WAF and API versioning I've addressed these two points in previous posts: Hardening Apache APISIX with the OWASP's Coraza and Core Ruleset API Versioning In short, Apache APSIX allows embedding the as a Rust plugin. Coraza WAF On the versioning side, one can choose three different approaches: path-based, query parameter-based, and header-based. APISIX supports all of them. Other items The remaining items are: Intrusion Detection Systems Secure Dependencies Use of Security Standards and Frameworks I'm afraid that APISIX cannot help with any of them. You need to address them on the upstream side. Conclusion In this two-post series, I've addressed most of the 16 practices to secure APIs with Apache APISIX. While I don't claim the list is exhaustive, it's a solid basis to improve the security of one's system. Originally published at on February 25th, 2024 A Java Geek

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

From Kotlin Scripting to Python: Why I Changed How I Automate

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

16 Best Practices For Securing Your APIs with Apache APISIX - Part 2

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

Apache APISIX vs. Spring Cloud Gateway

Apache APISIX Without etcd?

Creating a Poor Man's API Using PostgREST

Creating a Simple gRPC Service on the Client Side

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

Apache APISIX vs. Spring Cloud Gateway

Apache APISIX Without etcd?

Creating a Poor Man's API Using PostgREST

Creating a Simple gRPC Service on the Client Side

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps