HTTP vs HTTPS, Cookies, Sessions and CORS for API Testers

Three topics confuse new API testers more than anything else: why HTTPS matters when “the API works fine on HTTP”, how a website remembers you are logged in (cookies, sessions or tokens), and the famous red “blocked by CORS policy” error that appears in the browser while the same call works perfectly in Postman. This lesson explains all three with everyday examples and gives you a practical test checklist for each.

HTTP vs HTTPS (The Postcard vs Sealed Envelope Example)

How HTTPS works (simplified TLS handshake)

1. The client says hello and lists the TLS versions and ciphers it supports.
2. The server replies with its certificate (containing its public key) signed by a Certificate Authority such as Let’s Encrypt or DigiCert.
3. The client checks the certificate: trusted issuer, not expired, matches the domain name.
4. Both sides agree on a shared secret session key.
5. All HTTP data is now encrypted with that key.

The request and response inside are exactly the same as HTTP; only the transport is protected. That’s why everything you learned about methods, headers and status codes applies unchanged.

How to Test HTTPS for APIs

# See the TLS handshake and certificate details
curl -v https://sqatools.in/wp-json/sqa-api/v1/health 2>&1 | grep -E "SSL connection|subject|expire|issuer"

Cookies Explained for API Testers

A cookie is a small name-value pair that the server sets with a Set-Cookie response header. The browser stores it and automatically sends it back in a Cookie request header on every later request to that site.

HTTP/1.1 200 OK
Set-Cookie: session_id=8f2a9c1e77; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

GET /account HTTP/1.1
Cookie: session_id=8f2a9c1e77

Cookie attributes you must test

Sessions vs Tokens (JWT)

The practice API supports token login with refresh and logout, which you will test in detail in the JWT lesson of Module 3:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin@123"}' \
  "https://sqatools.in/wp-json/sqa-api/v1/auth/login"

These are public practice credentials published on the API practice page; never use real credentials on practice systems.

Session and token test cases

• After logout, the old session id or token is rejected (401).
• Session or token expires after the configured idle and absolute timeouts.
• A new session id is issued after login (prevents session fixation).
• Session ids are long and random, not sequential.
• Changing the password invalidates other sessions.
• Tokens never appear in URLs or logs.

What Is CORS? (And Why Postman Works When the Browser Fails)

Browsers follow the Same-Origin Policy: JavaScript on one origin (scheme + host + port) can’t read responses from another origin unless that server explicitly allows it. CORS is the mechanism a server uses to say “these other origins may read my responses”.

Simple vs pre-flighted requests

For “non-simple” requests (PUT, DELETE, PATCH, custom headers like Authorization, or JSON content type), the browser first sends an automatic OPTIONS pre-flight:

OPTIONS /api/cart HTTP/1.1
Origin: https://shop.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: authorization, content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://shop.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

Only if the pre-flight approves does the browser send the real DELETE.

CORS response headers

The SQA Tools practice API is CORS-enabled and exposes headers such as Location, ETag, Retry-After and X-Total-Count, which is why the “Send request” boxes in these lessons can show them.

CORS test cases

• Allowed origin: response contains the matching Access-Control-Allow-Origin.
• Unknown origin (e.g. https://evil.example): no allow-origin header for it.
• Security bug: the server reflects any Origin back and sends Allow-Credentials: true. Any website can then read logged-in users’ data.
• Access-Control-Allow-Origin: * combined with credentials is invalid and must not be used.
• Pre-flight OPTIONS returns 2xx with the right methods and headers.
• Headers the frontend needs (Location, ETag, pagination) are exposed.

# Simulate a browser pre-flight from another origin
curl -i -X OPTIONS "https://api.example.com/v1/cart" \
  -H "Origin: https://evil.example" \
  -H "Access-Control-Request-Method: DELETE"
# PASS if the response does NOT allow https://evil.example

Playwright: Checking Cookies, HTTPS and CORS Headers

import { test, expect } from '@playwright/test';

test('API is served only over HTTPS', async ({ request }) => {
  const res = await request.get('https://sqatools.in/wp-json/sqa-api/v1/health');
  expect(res.url()).toMatch(/^https:\/\//);
  expect(res.ok()).toBeTruthy();
});

test('session cookie has secure attributes', async ({ request }) => {
  // Replace with your application's login endpoint
  const res = await request.post('https://your-app.test/api/login', {
    data: { username: 'qa_user', password: process.env.QA_PASSWORD },
  });
  const setCookie = res.headersArray().filter(h => h.name.toLowerCase() === 'set-cookie');
  const session = setCookie.find(h => h.value.startsWith('session_id='));
  expect(session?.value).toContain('Secure');
  expect(session?.value).toContain('HttpOnly');
  expect(session?.value).toMatch(/SameSite=(Lax|Strict)/i);
});

test('CORS does not trust random origins', async ({ request }) => {
  const res = await request.fetch('https://your-app.test/api/cart', {
    method: 'OPTIONS',
    headers: { Origin: 'https://evil.example', 'Access-Control-Request-Method': 'DELETE' },
  });
  expect(res.headers()['access-control-allow-origin']).not.toBe('https://evil.example');
});

Use headersArray() for Set-Cookie because a response can contain several cookies with the same header name. Keep real passwords in environment variables, never in test code.

Common Mistakes

• Reporting a CORS error as an “API down” bug. Check the browser console and the response headers first; the API usually works in Postman.
• “Fixing” CORS with Access-Control-Allow-Origin: * on an API that uses cookies.
• Disabling certificate checks (ignoreHTTPSErrors, curl -k) in production tests.
• Storing JWTs in localStorage without considering XSS risk.
• Not testing what happens after logout or expiry.

Interview Questions: HTTPS, Cookies and CORS