Securing API Servers: What CORS, Headers, and Error

Messages Reveal About API Security

Introduction

In this article, I examined the security posture of a public API by inspecting its responses using Postman and Burp Suite. By analyzing CORS behavior, security-related headers, and error responses from the JsonPlaceholder API, I aim to show how much an API can unintentionally reveal about its security design. The goal is not to exploit the API, but to develop a security-focused mindset.

Tools used:

• Postman
• Burp Suite

Setup:

I created a Postman Collection and named it “JsonPlaceHolder API Review,” and it’ll contain all my requests throughout the project.

Creating a new Postman Collection

By clicking the three dots beside the New Collection, I renamed the collection.

Next, I created an environment variable for the base URL (https://jsonplaceholder.typicode.com/). This made requests easier to reuse and kept everything consistent.

Creating an environment variable

I created a GET request for an endpoint called “posts”:

Creating a GET Request

Step 1: Sending a Normal Request

I began by sending a simple request to the JsonPlaceHolder /posts endpoint:

GET {{base_url}}/posts

The server returned a successful 200 OK Response along with a JSON body, returning the user ID, title, and body of the posts. This established what a normal, successful response looked like before examining security-related details.

200 OK Response

Step 2: Observing CORS Behavior

Because browsers enforce CORS, I opened the same API call in Chrome and inspected the Network tab.

There, I could see headers like:

• Access-Control-Allow-Origin: true
• Access-Control-Expose-Headers

This showed that GitHub allows cross-origin access to its public API. This means a web page running on any domain can make JavaScript requests to the GitHub API and read the response, which is useful for public data but dangerous if sensitive endpoints were ever exposed under the same policy.