A couple of months ago, I stumbled upon this list of  Secure your API with these : 16 practices to secure your API 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. While it's debatable whether some points relate to security, versioning, the list is a good starting point anyway. In this two-post series, I'd like to describe how we can implement each point with Apache APISXI (or not). e.g., Authentication Authentication is about identifying yourself with a system. It requires a proof. provides two kinds of authentications: internal, with APISIX checking credentials, and external, when delegated to a third party. All authentication mechanisms work via plugins. Here's the current list of available authentication plugins. Apache APISIX Type Name Description Internal key-auth Authenticate via an HTTP Header Internal basic-auth Relies on a browser callback Internal jwt-auth Uses a JWT token to authenticate External authz-keycloak Delegates to Keycloak External authz-casdoor Delegates to Casdoor External wolf-rbac Delegates to wolf External openid-connect Delegates to an -compliant third-party OpenID Connect External cas-auth Delegates to a -compliant third-party CAS External hmac-auth Delegates to an -compliant third-party HMAC External authz-casbin APISIX assigns authenticated calls to a . For example, we can create a consumer authenticated with the plugin: consumer key-auth consumers:
  - username: john
    plugins:
      key-auth:
        key: mykey Every request containing the header with the key will be assigned to the consumer . apikey mykey john Authorization Authentication alone isn't enough. Once a request to a URL has been authenticated, we need to decide whether it's allowed to proceed further. That's the role of authorization. Authorization [...] is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular. More formally, "to authorize" is to define an access policy. -- Authorization on Wikipedia Apache APISIX implements authorization mainly via the plugin. Here's the most straightforward usage of the plugin: consumer-restriction consumer-restriction consumers:
  - username: johndoe                     #1
    plugins:
      keyauth:
        key: mykey

routes:
  - upstream_id: 1                        #2
    plugins:
      keyauth: ~
      consumer-restriction:
        whitelist:                        #3
          - johndoe Define a consumer Reference an already existing upstream Only allows defined consumers to access the route Most real-world authorization models avoid binding an identity directly to a permission. They generally bind a group (and even a role) so that it becomes easier to manage many identities. Apache APISIX provides the abstraction for this. consumer group consumer_groups:
  - id: accountants                      #1

consumers:
  - username: johndoe
    group_id: accountants                #2
    plugins:
      keyauth:
        key: mykey

routes:
  - upstream_id: 1
    plugins:
      keyauth: ~
      consumer-restriction:
        type: consumer_group_id          #3
        whitelist:
          - accountants Define a consumer group Assign the consumer to the previously defined consumer group Restrict the access to members of the defined consumer group, , i.e. accountants Input validation With Apache APISIX, you can define a set of JSON schemas and validate a request against any of them. My colleague Navendu has written an exhaustive blog post on the subject: . Your API Requests Should Be Validated I think it's not the API Gateway's responsibility to handle request validation. Each upstream has specific logic, and moving the validation responsibility from the upstream to the Gateway ties the latter to the logic for no actual benefit. In any case, the checkbox is ticked. IP Whitelisting Apache APISIX implements IP Whitelisting via the plugin. You can define either regular IPs or CIDR blocks. ip-restriction routes:
  - upstream_id: 1
    plugins:
      ip-restriction:
        whitelist:
          - 127.0.0.1
          - 13.74.26.106/24 Logging and Monitoring Logging and Monitoring fall into the broader category, also encompassing . Apache APISIX offers a broad range of Observability plugins in each category. Observability Tracing Type Name Description Tracing zipkin Collect and send traces according to the Zipkin specification Tracing skywalking Integrate with the project Apache SkyWalking Tracing opentelemetry Report data according to the OpenTelemetry specification Metrics prometheus Expose metrics in the Prometheus format Metrics node-status Expose metrics in JSON format Metrics datadog Integrate with Datadog Logging file-logger Push log streams to a local file Logging syslog Push logs to a Syslog server Logging http-logger Push JSON-encoded logs to an HTTP server Logging tcp-logger Push JSON-encoded logs to a TCP server Logging udp-logger Push JSON-encoded logs to a UDP server Logging kafka-logger Push JSON-encoded logs to a Kafka cluster Logging rocketmq-logger Push JSON-encoded logs to a RocketMQ cluster Logging loki-logger Push JSON-encoded logs to a Loki instance Logging splunk-hec-logging Push logs to a Splunk instance Logging loggly Push logs to a Loggly instance Logging elasticsearch-logger Push logs to an Elasticsearch instance Logging sls-logger Push logs to Alibaba Cloud Log Service Logging google-cloud-logging Push access logs to Google Cloud Logging Service Logging tencent-cloud-cls Push access logs to Tencent Cloud CLS Rate Limiting Rate Limiting protects upstreams from Distributed Denial of Services attacks, DDoS. It's one of the main features of reverse proxies and API Gateways. APISIX implements rate limiting through three different plugins: a.k.a The Plugin limits the number of concurrent requests to your services limit-conn The Plugin limits the number of requests to your service using the limit-req leaky bucket algorithm The Plugin limits the number of requests to your service by a given count per time. The plugin uses the Fixed Window algorithm. limit-count Let's use for the sake of example: limit-count routes:
  - upstream_id: 1
    plugins:
      limit-count:
        count: 10
        time_window: 1
        rejected_code: 429 The above configuration snippet protects the upstream from being hit by more than ten requests per second. It applies to every IP address because of the default configuration. The complete snippet would look like the following: routes:
  - upstream_id: 1
    plugins:
      limit-count:
        count: 10
        time_window: 1
        rejected_code: 429
        key_type: var
        key: remote_addr When dealing with APIs, there's a considerable chance you want to differentiate between your clients. Some might get a better rate for different reasons: they paid a premium offer, they are considered strategic, they are internal clients, etc. The same consumer could also use different IP addresses because they run on various machines with other APIs. Allowing the same consumer more calls because they execute their requests on a distributed infrastructure would be unfair. As it stands, the IP is not a great way to assign the limit; we prefer to use a named consumer or, even better, a consumer group. It's perfectly possible with APISIX: consumer_groups:
  - id: basic
    plugins:
      limit-count:
        count: 1
        time_window: 1
        rejected_code: 429
  - id: premium
    plugins:
      limit-count:
        count: 10
        time_window: 1
        rejected_code: 429

consumers:
  - username: johndoe
    group_id: basic
    plugins:
      keyauth:
        key: mykey1
  - username: janedoe
    group_id: premium
    plugins:
      keyauth:
        key: mykey2

routes:
  - upstream_id: 1
    plugins:
      key-auth: ~ Now, can only send a request every second, as he's part of the plan, while can request ten times as much as part of the premium plan. johndoe basic janedoe 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. Finally, we can also remove default HTTP response headers, such as , to make targeted attacks less likely. response-rewrite Server global_rules:                               #1
  - id: 1
    plugins:
      response-rewrite:
        headers:
          set:
            X-Content-Type-Options: nosniff #2
          remove:
            - Server                        #3 Do it 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 Conclusion We've seen how to configure Apache APISIX to secure your APIs against 7 of the 16 rules in the original list. The rules left could be less straightforward to implement; we will cover them in the second installment. Originally published at on February 20th, 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.

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

Error Management in Rust: Libraries That Support It and Best Practices

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

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

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 2

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