The Hidden Cost of 500 Internal Server Error
Tags: testing, security, tooling, api
Published: 2021-03-16 22:54:48

Web APIs are everywhere! We interact with APIs every day. We use APIs to write a tweet, discover music, make a purchase or anything else you can imagine. We write applications that are composed with other APIs using patterns such as [API Gateways](https://microservices.io/patterns/apigateway.html).

It is empowering to interact with a well designed and [documented](https://swagger.io/resources/open-api/) API to build the right solutions for yourself and your customers.

A well behaved API will use [HTTP response status codes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status) to let you know if you are doing something right (`200-209`) or wrong (`400-499`). 

If an API responds to you in the `4xx` range, you can usually solve the problem yourself by adjusting your request. A helpful API will respond with some clues on what you need to do to solve the problem. For instance:

```bash
HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
  "timestamp": "2021-03-16T18:57:30.918+00:00",
  "status": 400,
  "error": "Bad Request",
  "message": "Missing required field, 'name'.",
  "path": "/pets"  
}
```

In the example above, the response tells us that we are missing a 'name' field. We just need to update the request body and try again.

Over time, you will eventually get a different response... 🙀

```bash
HTTP/1.1 500 Internal Server Error

{
  "timestamp": "2021-03-16T18:57:30.918+00:00",
  "status": 500,
  "error": "Internal Server Error",
  "message": "",
  "path": "/foo"
}
```


## [500 Internal Server Error](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500)

The response _might_ have some helpful information included, but will usually be some opaque text telling you that _something_ went wrong. Was there something wrong with your request? Did you use an incorrect URL? You may encounter a 500 when interacting with the API on a web page that is provided by the API vendor; with the 500 buried in an XHR response.

Every consumer of the API now has to go through some or all of these steps:

* Look closely at the request for obvious errors and try again
* Start looking on stack overFlow/Google/etc for similar issues
* Contact support and wait...
* Maybe it was just temporary? -- try the request again
* ⚠️ A retry might also be dangerous - Did the request partially complete? Will my credit card be double billed now?

This cost, in terms of time and frustration, is compounded by every consumer that runs into the 500 response code with the API. The feeling of empowerment that developers gained using the API will start to fade away.

## What causes a 500 Internal Server Error?

Many 500 Internal Server Errors are simply due to lack of error handling in the implementation. Validation may be missing in some resource requests. Some input may fail to deserialize correctly such as a path or query parameter mismatch with the expected variable type.

Some 500s may be totally out of a developer's control such as failing infrastructure.

Other API errors may be indicative of something more serious (or security-related) happening such as SQL Injection or [insecure deserialization](https://portswigger.net/web-security/deserialization).

## API Fuzzing to the rescue!

API developers can try to find these issues early with [negative testing](https://www.guru99.com/positive-and-negative-testing.html). Without sufficient planning, negative testing is often ignored as most testing emphasis is placed on positive testing; ensuring an API does what it should on the [happy path](https://en.wikipedia.org/wiki/Happy_path).

This is where [fuzzing](https://en.wikipedia.org/wiki/Fuzzing) comes in! API Fuzzing is technique where a comprehensive suite of inputs is generated to test an API. By using fuzzing techniques to generate inputs and observing the response from the application, an API fuzzer can quickly iterate through multitudes of test cases to find weakness in an API’s functionality or security.

When fuzzing an API, we should consider any 500 Internal Server Errors as 'buggy' endpoints. They are at minimum a waste of time for our customers and API owners to deal with, and at worst a possible symptom of serious underlying issues.

## [Mayhem for API](https://mayhem4api.forallsecure.com)

Mayhem for API is an API Fuzzing tool available today that you can use to fuzz an API that is documented with a [swagger/OpenAPI](https://swagger.io/resources/open-api/) specification or [Postman collection](https://www.postman.com/). [You can start fuzzing your APIs today totally free for 30 days](https://mayhem4api.forallsecure.com/signup)!

<video id="mapi" src="https://storage.googleapis.com/forallsecure-website.appspot.com/mapi_compressed.mov" controls></video>

The tool will report any 500 errors it discovers - along with the request that was sent and the response returned by the API.

![](https://mayhem4api.forallsecure.com/downloads/img/sample-report.png)

By running Mayhem for API as part of your build pipeline -- you can spend your time solving real customer problems and let the API fuzzer find 500 Internal Server Errors for you.

## Other API Fuzzing tools

As API fuzzing grows in maturity - we will see lots of innovation in the space. Here are a few other tools that are in active development:

* [Microsoft RESTler](https://github.com/microsoft/restler-fuzzer)
* [GitLab Web API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)

Happy fuzzing!