Testing API response headers: Are there any best practices to be followed?

So while testing an API I got the impression that just checking response bodies and status codes isn’t enough.
There’s a whole lot of information in the response headers. But the API I’m working with already has the standards met, presumably. This got me thinking if there’s a base criteria for response headers to be present in an API.
I’d love some resources on this subject.
.
.
.
A vague idea in my mind is to run some security tests through ZAP? I just want to be sure I’m not fooling myself here.

You’re thinking like a developer now. Turn it around and think like a tester.
Imagine some kind of risk related to the headers:

  • if some exist when they shouldn’t?
  • if some don’t exist when they should?
  • if some exist with values that don’t make sense.
    One way to go through can be this one from a security perspective:
    OWASP Secure Headers Project | OWASP Foundation

But there’s the integration side as well: UI with API, API with API, etc.
Another option to test: caching at API level done through headers.
Another one: custom headers to indicate some specific logic functions;
Another example: is the chained APIs and response codes/messages consistency and meaning.

An interesting issue related to API response headers that I found out recently by chance:

  • There’s a Clear-Site-Data header which we implemented as recommended after a penetration testing review.
  • When pressing Log out button in the UI an API request to invalidate the session is happening. The response contains the Clear-Site-Data header;
  • The browser executes the API header command before going to the UI.
  • The UI had a conflict/race condition and couldn’t delete the user data stored and couldn’t redirect the user to the Logout.
  • It took a developer almost two days to figure out this conflict and give up on refactoring, deciding to remove the API response header.

I’m just trying to expand the horizon of an interesting potential area of investigation.
I don’t know if there are general guidelines on this topic. Maybe some have, I’d be curious.

1 Like

About responses: Do not only rely on them, but check that the intended changes where made.
Your API may return 200 and the actual operation still could have failed (and the other way around).
The developers have to implement error handling correctly and that should be tested too. There is no magic that makes status codes working out-of-the-box

I also consider an API not only as interface, but being a door to a whole system (behavior).
They are not only for moving data from A to B, but can also trigger demanding calculations by that.
APIs are on way to use a system.
Chain some API calls and you can simulate user actions like paying at an online shop.

1 Like

It’s always easy to quickly run through: https://securityheaders.com/

A common mistake is to always expose the Server headers or any kind of platform versioning etc. What you really want is, having it set to Hidden.

image

It’s interesting to see you talk about response headers but have you tried adding request headers? :slight_smile:

Such as XFF? or adding other Host Headers. This could lead to for example:

  • Web cache poisoning
  • BLF
  • SSRF
  • SQLi

Here’s some more info about these: How to identify and exploit HTTP Host header vulnerabilities | Web Security Academy
And some labs to test them out online: All labs | Web Security Academy

There is a lot more out there … :stuck_out_tongue:

That’s an interesting question:

  • How does the API work for the consumer and how could it be made better for them?..Ask the consumer

Error handling is something I’m specifically having an eye on.
As for the actual operation succeeding, I suppose there’s broadly 2 ways to check that? The UI and the database.

1 Like

Yes security testing surely is quite a vast topic. I’ll check out the links.
Good suggestion about the request headers though.

1 Like

Database for sure.
UI may depend. It should work for anything aside the API call the UI itself uses.

1 Like