Response Headers

Introduction

After an API server processes an HTTP request, it sends an HTTP response back to the client. That response is made of the status line, response headers, a blank line, and the response body. The response body usually contains the business data or error information, but the response headers describe how the client should interpret, cache, secure, store, decompress, redirect, or otherwise handle that response.

Response headers are easy to ignore because they are not always visible in the main body output. Many beginners focus only on the status code and JSON response body. In real API testing, that is not enough. A response can return correct JSON data but declare the wrong Content-Type. A response can return sensitive account information but allow browser or proxy caching. A login response can set cookies without HttpOnly or Secure flags. A file download can return the right bytes but miss the Content-Disposition header needed for a clean download experience.

For API testers, response header validation is essential because headers affect client parsing, browser behavior, caching, authentication, security, performance, compression, redirects, file downloads, rate limiting, and cross-origin access. Incorrect headers may not always break a simple Postman request, but they can break a browser application, mobile client, integration service, CDN behavior, or security policy in production.

This tutorial explains response headers from a practical API testing point of view. It covers what response headers are, how they appear in an HTTP response, why they matter, common response headers, request headers vs response headers, validation techniques, examples in REST Assured, Postman, and Karate, real-world use cases, common mistakes, and interview-ready explanations.

What Are Response Headers?

Response headers are HTTP headers sent by the server to the client as part of an HTTP response. They are key-value pairs that provide metadata about the response. They do not usually contain the main business object itself; instead, they describe the response and guide the client on how to process it.

A simple definition is this: response headers are key-value pairs sent by the server that describe the HTTP response and provide additional information about content format, caching, cookies, security, redirects, compression, and other response behavior.

For example, the header Content-Type: application/json tells the client that the response body is JSON. The header Cache-Control: no-store tells clients and intermediaries not to store the response. The header Set-Cookie instructs the browser to store a cookie. The header Location may tell the client where a newly created resource is available or where it should redirect.

Headers are part of the API contract. Even when the response body is correct, wrong headers can produce wrong behavior. That is why professional API testing includes header validation alongside status code and response body validation.

Response Header Format

Response headers follow a simple key-value format. A header name is followed by a colon and then the header value:

Header-Name: Header-Value

A common example is:

Content-Type: application/json

Some headers contain one simple value. Others contain multiple directives separated by semicolons or commas. For example, a Set-Cookie header may include the cookie name, cookie value, expiry, path, Secure flag, HttpOnly flag, and SameSite attribute. A Cache-Control header may include directives such as no-cache, no-store, max-age, private, or public.

Header names are case-insensitive in HTTP, but teams should still use consistent casing in documentation and tests for readability. Header values may be case-sensitive depending on the header. Testers should validate the behavior and documented value, not only the visual spelling.

HTTP Response Structure

An HTTP response begins with the status line. Then response headers appear one per line. After the headers, a blank line separates the metadata from the response body. Everything after the blank line is the body if a body exists.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 85
Cache-Control: no-cache

{
  "id": 101,
  "name": "John"
}

In this example, the status line is HTTP/1.1 200 OK. The response headers are Content-Type, Content-Length, and Cache-Control. The blank line comes after the headers. The JSON object below the blank line is the response body.

This structure helps testers understand what to validate. Status code validation confirms the high-level result. Header validation confirms response metadata and handling rules. Body validation confirms returned data or error content. A good API test strategy checks all three where relevant.

Why Response Headers Are Important

Response headers tell the client how to interpret the response. If a response body contains JSON but the Content-Type says text/plain, a strict client may not parse it as JSON. If a PDF download returns application/octet-stream instead of application/pdf, browser behavior may be different from what users expect. Content-Type is one of the most common headers testers validate because it directly affects response parsing.

Response headers also control caching. If sensitive user data is returned with cache-friendly headers, browsers, proxies, or shared caches may store data that should remain private. Banking, healthcare, login, account, and personal profile APIs need careful cache validation. Headers such as Cache-Control, Expires, ETag, and Last-Modified influence how clients reuse responses.

Security behavior is also controlled through headers. Browser-facing APIs may require headers such as Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and cookie attributes. Missing or weak security headers may expose applications to browser-based risks. Not every API needs every header, but critical web applications should have a defined security header policy.

Headers also support redirects, file downloads, compression, cookies, correlation, observability, CORS, and rate limiting. This makes header validation practical, not theoretical. When headers are wrong, users may see stale data, downloads may fail, browsers may block requests, cookies may be insecure, or clients may retry incorrectly.

Common Response Headers

Common response headers include Content-Type, Content-Length, Cache-Control, Expires, ETag, Last-Modified, Set-Cookie, Location, Server, Date, Content-Encoding, Access-Control-Allow-Origin, Retry-After, X-RateLimit headers, and several security headers. Each one has a different purpose and should be validated based on endpoint behavior and application requirements.

Not every response needs every header. A JSON API response usually needs Content-Type. A file download usually needs Content-Type, Content-Length where known, and often Content-Disposition. A login response may include Set-Cookie or token-related body data depending on authentication design. A rate-limited response may include Retry-After or rate-limit metadata. A newly created resource may include Location.

Good testing does not mean asserting a long fixed header list on every endpoint. It means knowing which headers matter for the endpoint and validating those consistently. Overly rigid header tests can become noisy, but missing critical headers can lead to production defects.

Content-Type Header

The Content-Type header specifies the format of the response body. It helps the client decide how to parse the returned content. For JSON responses, the value is usually application/json. For XML, it may be application/xml or text/xml. For plain text, it may be text/plain. For PDF files, it may be application/pdf. For PNG images, it may be image/png.

Content-Type: application/json

Content-Type validation is important because a mismatch can break client applications. A browser, mobile app, or integration client may use the header to choose a parser. If the server returns HTML error pages while clients expect JSON error bodies, automated clients may fail in unexpected ways. Testers should verify Content-Type for success and error responses.

Content-Type may also include a charset, such as application/json; charset=utf-8. Tests should allow documented variations while still confirming that the media type is correct. A practical assertion often checks that Content-Type contains application/json rather than requiring an exact string if the charset may vary.

Content-Length Header

The Content-Length header indicates the size of the response body in bytes. It can be useful for download progress, performance monitoring, client buffering, and detecting incomplete responses. For example:

Content-Length: 245

Not all responses include Content-Length. Responses using chunked transfer encoding may not send it. Compressed responses may also require careful interpretation because the length may refer to compressed bytes rather than the decompressed body. Testers should understand the API and server behavior before making strict assertions.

For file downloads and export APIs, Content-Length is often useful. A PDF, image, ZIP, or Excel export that returns zero bytes or unexpectedly tiny output may indicate a defect. Testers can validate that the response is not empty and that the file opens correctly. Content-Length alone does not prove content is valid, but it helps detect obvious problems.

Cache-Control and Expires Headers

Cache-Control controls how clients, browsers, proxies, and shared caches may store or reuse a response. Examples include:

Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: max-age=3600

The Expires header specifies a date and time after which cached content becomes stale. Modern APIs often rely more on Cache-Control, but Expires still appears in many systems.

Cache validation is important for sensitive APIs. Authentication responses, profile data, banking information, healthcare records, and private reports should generally avoid unsafe caching. Public catalog data, static reference data, or documentation endpoints may be cacheable. The expected behavior depends on the endpoint and security requirements.

A common testing mistake is ignoring cache headers until a stale data issue appears in production. If users see old balances, old permissions, old order statuses, or cached private data, incorrect caching rules may be part of the cause. API testers should include cache header checks for endpoints where freshness or privacy matters.

ETag and Last-Modified Headers

ETag is a resource version identifier. It helps clients make conditional requests and avoid downloading unchanged content. Last-Modified indicates when the resource was last changed. Together with request headers such as If-None-Match and If-Modified-Since, these headers support efficient caching and synchronization.

ETag: "abc123xyz"
Last-Modified: Tue, 01 Jul 2026 10:30:00 GMT

For APIs that use ETags, testers should verify that the ETag changes when the resource changes and remains stable when the resource is unchanged. Conditional GET requests should return 304 Not Modified when appropriate. Update requests using If-Match may prevent lost updates when multiple clients modify the same resource.

These headers are especially useful for content APIs, document APIs, configuration APIs, and systems where clients sync data. They are not mandatory for every API, but when implemented, they should be tested carefully because incorrect version metadata can cause stale reads or overwrite problems.

Set-Cookie Header

The Set-Cookie header instructs the client, usually a browser, to store a cookie. Cookies may be used for sessions, authentication, preferences, CSRF tokens, tracking consent, or other browser-based behavior. A simple example is:

Set-Cookie: sessionId=ABC123; HttpOnly; Secure; SameSite=Lax

Cookie validation is security-sensitive. Authentication cookies should usually use HttpOnly so client-side scripts cannot read them. They should use Secure so they are sent only over HTTPS. SameSite helps reduce cross-site request risks. Expiry and path rules should match the application design.

Testers should verify cookie name, value presence, expiry or max-age, domain, path, Secure flag, HttpOnly flag, SameSite attribute, and whether cookies are set only when expected. Login, logout, session timeout, refresh, and permission changes may all affect cookies.

Location Header

The Location header specifies a URI. It is commonly used in redirects and resource creation responses. For a redirect, the server may return a 3xx status code and a Location header pointing to the new destination. For a 201 Created response, Location may point to the newly created resource.

HTTP/1.1 201 Created
Location: /users/101

Testers should verify that Location is present when required, points to the correct resource, uses the expected URL format, avoids unsafe open redirects, and remains consistent with the response body. If a POST creates user ID 101 but Location points to /users/102, the response is inconsistent.

Redirect validation should include allowed destinations. APIs should not allow attackers to control redirects to malicious domains unless the behavior is carefully restricted and documented. Location may seem simple, but it can carry security and usability implications.

Server and Date Headers

The Server header identifies web server software, such as nginx or Apache. Some organizations suppress or minimize this header because detailed server information can help attackers fingerprint systems. Whether this header should be present depends on security policy.

The Date header indicates when the response was generated. It can be useful for caching, logging, debugging, and time-based behavior. Testers do not usually validate the exact Date value in normal functional tests, but they may verify presence when required by platform standards.

Server and Date headers are examples of metadata headers that may not directly affect business data but still matter operationally. In regulated or security-conscious environments, response header policies may specify exactly what is allowed.

Content-Encoding Header

Content-Encoding specifies compression or encoding applied to the response body. Common values include gzip and br. Compression reduces response size and improves performance, especially for large JSON, HTML, CSS, JavaScript, or text responses.

Content-Encoding: gzip

Testers should verify that compressed responses can be decompressed by the client and that the body remains valid after decompression. They should also check that compression is not applied in unsafe ways to highly sensitive responses if the organization has security restrictions around compression and secrets.

In many tools, decompression happens automatically. That can hide header behavior from beginners. It is still useful to inspect raw headers and understand whether the API is compressed, especially when investigating performance, proxy behavior, or client parsing issues.

CORS Headers

CORS headers control whether browser-based JavaScript running from one origin can access resources from another origin. A common CORS header is:

Access-Control-Allow-Origin: https://example.com

Other common CORS headers include Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, Access-Control-Expose-Headers, and Access-Control-Max-Age. These headers matter primarily for browser clients. A request may work in Postman but fail in a browser because CORS headers are missing or too restrictive.

Testers should verify that allowed origins, methods, and headers match the application's CORS policy. Overly permissive CORS settings can create security risk. Overly restrictive settings can break legitimate frontend applications. Preflight OPTIONS requests may also need validation because browsers send them before certain cross-origin requests.

Security Headers

Security headers help protect browser-facing applications and APIs from common risks. Common examples include Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and sometimes Permissions-Policy.

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'

Not every API response needs every browser security header, especially if the API is used only server-to-server. However, web applications and browser-consumed APIs should follow a clear security header standard. Missing headers may expose the application to clickjacking, MIME sniffing, insecure transport downgrade, referrer leakage, or script injection impact.

API testers should coordinate with security requirements rather than inventing their own header policy. The test should validate the organization's expected security baseline.

Rate Limit and Retry Headers

Many APIs include rate limit headers to tell clients how many requests remain, when limits reset, or when to retry. Header names vary by API, but common examples include X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, and Retry-After.

Retry-After: 60
X-RateLimit-Remaining: 0

Rate limit headers help clients behave responsibly. If a client receives 429 Too Many Requests, Retry-After can tell it how long to wait before trying again. Without this metadata, clients may retry aggressively and worsen load.

Testers should verify rate limit headers where implemented. They should check successful requests near the limit, the response when the limit is exceeded, reset behavior, and whether headers are accurate. These tests should be run carefully in controlled environments to avoid disrupting shared systems.

Response Headers vs Request Headers

Request headers are sent by the client to describe the request. Response headers are sent by the server to describe the response. Request headers may include Authorization, Content-Type, Accept, User-Agent, API keys, correlation IDs, and tenant identifiers. Response headers may include Content-Type, Content-Length, Cache-Control, Set-Cookie, Location, Content-Encoding, and security headers.

The direction is the main difference. Request headers tell the server what the client is sending or asking for. Response headers tell the client what the server is sending or instructing. Both are key-value pairs, and both are part of HTTP communication.

In testing, the two are connected. A request Accept header may influence the response Content-Type. A request If-None-Match header may influence response status and ETag behavior. A request Origin header may influence CORS response headers. Understanding this relationship helps testers design better scenarios.

Response Header Validation in API Testing

Response header validation means verifying that the server returns the expected metadata for a given response. The validation depends on endpoint type. A JSON API should return the expected Content-Type. A newly created resource may require a Location header. A sensitive API should return safe cache headers. A login response should set cookies securely if cookie-based authentication is used. A browser-facing API should follow CORS and security header rules.

Testers should validate important headers for both success and error responses. Error responses often reveal inconsistent behavior. For example, a successful API response may return application/json, but a gateway error may return text/html. A login success response may set secure cookies, but an error response may miss cache-control headers. These differences can matter in production.

Good header validation is targeted. Do not assert every header value strictly unless the contract requires it. Some headers, such as Date or generated correlation IDs, change on every response. Tests should assert patterns, presence, or meaningful constraints instead of brittle exact values.

Content-Type Validation

Content-Type validation confirms that the response body format matches the declared media type. If the endpoint returns JSON, verify that the Content-Type contains application/json and that the body is valid JSON. If the endpoint returns a PDF, verify application/pdf and that the file opens as a PDF. If the endpoint returns XML, verify the XML media type and well-formed XML.

This validation catches a common integration issue: HTML error pages returned from API gateways, proxies, or web servers. A client expecting JSON may fail when it receives an HTML error page. A human looking only at the status code may miss the format mismatch.

For APIs that support content negotiation, tests should vary the Accept header and verify the response format. If a client asks for XML and the API supports XML, the response should return XML. If the client asks for an unsupported type, the API should return the documented behavior.

Cache Header Validation

Cache header validation checks whether Cache-Control, Expires, ETag, and Last-Modified match the endpoint's caching requirements. Public reference data may be cacheable. Sensitive user data should usually avoid shared caching. Frequently changing data may need no-cache or short max-age. Static assets may use longer caching.

For sensitive endpoints, testers should verify that headers such as Cache-Control: no-store or other organization-approved directives are present. For cacheable endpoints, testers can verify max-age, ETag behavior, conditional requests, and freshness behavior.

Caching defects can be subtle. They may not appear during a single API call. They appear when clients reuse old data, proxies store responses unexpectedly, or browsers serve stale content. Header validation is a practical way to prevent those issues early.

Cookie Header Validation

When APIs use cookies, Set-Cookie validation becomes important. Testers should verify that cookies are set only when expected and cleared properly during logout. Authentication cookies should have security attributes such as HttpOnly, Secure, and SameSite according to application policy.

Cookie expiry should also be validated. Session cookies may expire when the browser closes. Persistent cookies may have Max-Age or Expires. A remember-me feature may use a longer expiry than a normal session. Incorrect expiry can cause users to be logged out too soon or remain logged in longer than allowed.

Cookie path and domain settings affect where the cookie is sent. Overly broad settings can increase risk. Overly narrow settings can break application behavior. API testers working on browser-based systems should treat cookie headers as part of authentication and session validation.

CORS Header Validation

CORS validation is important when APIs are consumed by browser applications hosted on a different origin. A request can work in Postman because Postman is not restricted by browser CORS rules, but the same request can fail from JavaScript in the browser. This makes CORS a common source of confusion.

Testers should validate allowed origins, allowed methods, allowed headers, credentials behavior, exposed headers, and preflight responses. For example, if the frontend is hosted at https://app.example.com, the API may need to allow that origin. If the frontend sends Authorization and Content-Type headers, the preflight response must allow them.

Security also matters. Using * as an allowed origin may be acceptable for public APIs without credentials, but it is not appropriate for sensitive credentialed APIs. The correct policy depends on the application's architecture and risk model.

Security Header Validation

Security header validation checks whether required browser security headers are present and correctly configured. These headers help reduce the impact of common attacks. For example, X-Content-Type-Options with nosniff prevents browsers from guessing a different content type. X-Frame-Options or frame-ancestors in Content-Security-Policy can reduce clickjacking risk. HSTS enforces HTTPS after the browser has seen the header.

Testers should validate security headers according to the project standard. The goal is not to copy every security header from the internet. Some values can break legitimate behavior if configured without understanding. For example, a strict Content-Security-Policy can block required scripts if not planned carefully.

Security headers should be checked across important paths, not only the home page. Login, account, payment, admin, and API error responses may all need the same baseline.

Location Header Validation

Location header validation applies to redirects and resource creation. For 201 Created responses, Location should point to the created resource if the API contract requires it. For redirects, Location should point to the expected target.

Testers should check that Location is present when expected, absent when not expected, and uses safe URLs. Open redirect testing is important when user input can influence redirect destinations. A malicious redirect can be used in phishing or token leakage scenarios.

Location should also be consistent with the response body. If the response body says the created order ID is 500, a Location value ending in /orders/500 is expected. Inconsistency between body and headers should be treated as a defect.

Response Header Validation Checklist

A practical response header validation checklist includes Content-Type, Content-Length where relevant, Cache-Control, Expires, ETag, Last-Modified, Set-Cookie, Location, Content-Encoding, Date, Server, CORS headers, security headers, rate limit headers, Retry-After, correlation IDs, and any application-specific headers documented by the API.

The checklist should be adapted to each endpoint. A JSON data endpoint mainly needs Content-Type, cache policy, security policy, and sometimes correlation headers. A file download needs Content-Type, Content-Length, and Content-Disposition. A login endpoint needs cache policy and secure cookies if cookies are used. A rate-limited endpoint needs Retry-After and rate-limit metadata.

The best header checks are intentional. They validate headers that affect behavior, security, performance, or contract compatibility. They avoid brittle assertions on incidental values that change frequently and are not part of the contract.

REST Assured Example

REST Assured can validate response headers directly. A simple Content-Type check may look like this:

given()
.when()
  .get("/users")
.then()
  .header("Content-Type", containsString("application/json"));

This verifies that the response declares JSON content. More complete tests can validate Cache-Control, Location, Set-Cookie, or custom headers. For dynamic headers, tests can assert presence or pattern. For example, a correlation ID may only need to be present and non-empty.

For file downloads, REST Assured can validate Content-Type and then extract the body bytes for file validation. For security checks, it can assert that expected headers are present on important endpoints. These validations work well in regression suites because headers can change accidentally during server, gateway, or framework updates.

Postman Example

Postman can validate response headers in the Tests tab. A simple example is:

pm.test("Content-Type header is present", function () {
  pm.response.to.have.header("Content-Type");
});

A more specific assertion can check the value:

pm.test("Response is JSON", function () {
  pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

Postman is useful for exploring headers manually because the Headers tab shows response metadata clearly. Newman can run those same checks in CI. Teams should convert important header expectations into automated tests rather than relying on manual inspection.

Karate Example

Karate supports header validation with readable syntax:

Then match header Content-Type contains 'application/json'

Karate can also validate cookie headers, response headers, and CORS headers. Because Karate scenarios can include both request and response expectations, it is useful for testing how request headers such as Accept or Origin influence response headers.

For example, a CORS test can send an Origin header and validate Access-Control-Allow-Origin. A content negotiation test can send an Accept header and verify Content-Type. This makes header behavior explicit in the API test.

Real-World Examples

A JSON API response commonly includes:

Content-Type: application/json

A file download may include:

Content-Type: application/pdf
Content-Length: 125000

A login API using cookies may include:

Set-Cookie: sessionId=ABC123; HttpOnly; Secure; SameSite=Lax

A resource creation API may include:

HTTP/1.1 201 Created
Location: /users/101

A rate-limited API may include Retry-After and rate limit metadata. A browser-facing API may include CORS headers. A secure production site may include HSTS and other browser security headers. Each example shows that response headers communicate behavior beyond the response body.

Best Practices

Always validate important response headers. At minimum, API tests should verify Content-Type for endpoints that return structured bodies. Sensitive endpoints should validate cache headers. Cookie-based authentication should validate cookie security attributes. Browser-facing APIs should validate CORS and security headers. File downloads should validate file-related headers.

Ensure Content-Type matches the response body. Verify caching headers for sensitive APIs. Validate security headers according to project standards. Check cookies for Secure, HttpOnly, SameSite, domain, path, and expiry where relevant. Verify CORS configuration for browser-based APIs. Avoid exposing unnecessary server information if the security policy requires suppression.

Keep tests practical and maintainable. Use exact assertions for stable contract headers and flexible assertions for dynamic headers. Validate both success and error responses. Review header behavior when infrastructure changes, such as moving behind a gateway, CDN, reverse proxy, or load balancer, because those components often add, remove, or rewrite headers.

Common Mistakes

A common mistake is ignoring response headers completely. Validating only the response body may miss caching, security, content negotiation, cookie, compression, redirect, or browser behavior issues. Headers are not decorative metadata; they influence real client behavior.

Another mistake is returning incorrect Content-Type. If an API returns JSON while declaring text/plain, clients may parse the response incorrectly. If an error response returns HTML while the API contract says JSON, automated clients may fail. Testers should catch these mismatches.

Missing security headers are another common issue. Production systems may need a defined security header baseline. If headers are added only on some routes and missing from error routes, the application may behave inconsistently. Incorrect cache configuration is also common. Sensitive APIs should generally not be cached by shared caches.

Finally, some tests become too brittle by asserting every header exactly. Headers such as Date, Content-Length, generated request IDs, and server-managed values may change. Tests should focus on documented and meaningful expectations.

Interview Questions

A common interview question is: what are response headers? A strong answer is that response headers are HTTP headers sent by the server to the client as part of an HTTP response. They provide metadata about the response, such as content format, size, caching, cookies, redirects, compression, CORS, and security policies.

Another question is: why are response headers important? They tell the client how to interpret, cache, secure, and process the response. Without correct headers, clients may parse data incorrectly, cache sensitive data, fail browser CORS checks, store insecure cookies, or miss redirect information.

Interviewers may ask for examples of common response headers. A good answer includes Content-Type, Content-Length, Cache-Control, Expires, ETag, Last-Modified, Set-Cookie, Location, Date, Server, Content-Encoding, Access-Control-Allow-Origin, Retry-After, rate-limit headers, and security headers such as Strict-Transport-Security and Content-Security-Policy.

A testing-focused answer should mention that response headers should be validated along with status code and response body, especially for content type, cache policy, cookies, CORS, security, redirects, compression, and file downloads.

Interview-Ready Explanation

Response headers are HTTP headers sent by the server to the client as part of an HTTP response. They provide metadata about the response, such as the response body format through Content-Type, response size through Content-Length, caching rules through Cache-Control and Expires, resource versioning through ETag and Last-Modified, cookies through Set-Cookie, redirects or created resource locations through Location, compression through Content-Encoding, CORS behavior through Access-Control-Allow headers, and browser security policies through security headers.

In API testing, response headers should be validated because they affect how clients interpret, store, secure, and process the response. A correct response body with incorrect headers can still cause defects. For example, JSON returned with the wrong Content-Type may fail parsing, sensitive data with unsafe cache headers may be stored, cookies without Secure or HttpOnly may create security risk, and missing CORS headers may break browser clients.

A strong API test validates response headers based on the endpoint contract and risk. It checks Content-Type, caching, security headers, cookies, Location, Content-Encoding, CORS, rate limit headers, and application-specific headers where relevant. Header validation should be included for both success and error responses.

Key Takeaway

Response headers describe the HTTP response and guide the client on how to process it. They may control content parsing, caching, cookies, redirects, compression, CORS, security, rate limiting, and operational metadata. They are a core part of the API contract, not an optional detail.

The practical testing rule is simple: validate the headers that affect behavior, security, compatibility, and client handling. Check Content-Type, cache rules, cookies, CORS, security headers, Location, compression, and file download headers where relevant. A response is correct only when the status code, response body, and response headers all agree with the expected API behavior.