DEV Community: tiger Z

Code Quality Best Practices for Teams

tiger Z — Tue, 02 Jun 2026 08:56:46 +0000

Published May 30, 2026 · 8 min read · 🏷️ Best Practices
# Code Quality Best Practices for Teams

    Good code is not just about functionality — it's about readability, maintainability, and collaboration. These practices help teams write code that stands the test of time.

    ## Naming Conventions

    Names should be self-documenting. If you need a comment to explain what a variable is, rename it:

// Bad
const x = users.filter(u => u.s === 'active');
const d = new Date();
const tmp = processData(data);

// Good
const activeUsers = users.filter(user => user.status === 'active');
const currentTimestamp = new Date();
const processedData = processData(rawData);

    **Variable names:** nouns, descriptive (`userData`, `totalAmount`)

    **Function names:** verbs or verb phrases (`fetchUser`, `calculateTotal`, `isValidEmail`)

    **Constants:** ALL_CAPS with underscores (`MAX_RETRY_COUNT`, `DEFAULT_TIMEOUT`)

    ## Functions: Do One Thing

    Each function should do one thing well. A good test: if you need "and" to describe what it does, split it:

// Bad: Does multiple things
function processUser(user) {
  validateUser(user);  // validation
  saveToDatabase(user);  // persistence
  sendWelcomeEmail(user);  // side effect
  return user;
}

// Good: Single responsibility
function validateUser(user) { ... }
function saveUser(user) { ... }
function notifyUser(user, type) { ... }

function registerUser(user) {
  validateUser(user);
  const savedUser = saveUser(user);
  notifyUser(savedUser, 'welcome');
  return savedUser;
}

    ## Keep Functions Small

    Ideal: less than 20 lines. Good: less than 50 lines. If a function exceeds 100 lines, strongly consider splitting it.

// Bad: Function doing too much
async function handleOrder(order) {
  // 200+ lines of validation, calculation, persistence, notification...
}

// Good: Composed of smaller functions
async function handleOrder(order) {
  const validated = validateOrder(order);
  const calculated = calculatePricing(validated);
  const saved = await persistOrder(calculated);
  await notifyCustomer(saved);
  return saved;
}

    ## Avoid Magic Numbers

// Bad: What do these numbers mean?
if (user.age > 18 && retryCount  5000) {
  processPayment(amount * 0.95);
}

// Good: Named constants explain the intent
const MINIMUM_AGE = 18;
const MAX_RETRY_COUNT = 3;
const PAYMENT_TIMEOUT_MS = 5000;
const LOYALTY_DISCOUNT = 0.05;

if (user.age > MINIMUM_AGE && retryCount  PAYMENT_TIMEOUT_MS) {
  processPayment(amount * (1 - LOYALTY_DISCOUNT));
}

    ## Early Returns (Guard Clauses)

    Handle edge cases and invalid inputs at the start with early returns:

// Bad: Nested conditionals
function processUser(user) {
  if (user) {
    if (user.email) {
      if (user.isActive) {
        // main logic here, deeply nested
      }
    }
  }
}

// Good: Early returns for edge cases
function processUser(user) {
  if (!user) return null;
  if (!user.email) return null;
  if (!user.isActive) return null;

  // main logic at top level
  return processActiveUser(user);
}

    ## Error Handling

    Handle errors explicitly. Never swallow exceptions silently:

// Bad: Silently ignoring errors
try {
  await sendEmail(user.email);
} catch (e) {
  // Nothing happens, error is lost
}

// Good: Explicit handling
try {
  await sendEmail(user.email);
} catch (error) {
  logger.error('Failed to send email', { userId: user.id, error });
  throw new EmailDeliveryError('Failed to send notification', { cause: error });
}

// Or handle gracefully
try {
  await sendEmail(user.email);
} catch (error) {
  logger.warn('Email failed, will retry', { userId: user.id });
  await queueForRetry(user.id);
}

    ## Comments That Add Value

    Good comments explain _why_, not _what_. The code shows what, comments explain why:

// Bad: Comments that state the obvious
// Increment counter by 1
counter++;

// Loop through users
for (const user of users) { }

// Good: Comments explain non-obvious decisions
// Using linear search here despite O(n) because:
// 1. Array is guaranteed to be small ( $100
// See: Tax Compliance Doc #2847
const taxRate = order.total > 100 ? 0.08 : 0;

    ## Consistent Code Formatting

    Use automated formatting. Debating formatting in code reviews is a waste of time:

// Use Prettier for JavaScript/TypeScript
// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100
}

// Use ESLint for code quality rules
// .eslintrc
{
  "extends": ["eslint:recommended"],
  "rules": {
    "no-unused-vars": "error",
    "prefer-const": "error"
  }
}

    ## Type Safety

    Use TypeScript or JSDoc for JavaScript. Types catch bugs at compile time:

// Bad: Any type, no safety
function processOrder(order) {
  return order.total * order.quantity;  // What if these are undefined?
}

// Good: Explicit types
interface OrderLineItem {
  total: number;
  quantity: number;
}

interface Order {
  items: OrderLineItem[];
  customerId: string;
}

function processOrder(order: Order): number {
  return order.items.reduce((sum, item) => sum + item.total * item.quantity, 0);
}

    ## Writing Testable Code

    Testable code is usually better code. Characteristics:


      - **Pure functions**: Same input → Same output, no side effects

      - **Dependency injection**: Pass dependencies as parameters

      - **Small, focused functions**: Easy to test in isolation

      - **Single responsibility**: Clear input/output

// Hard to test: dependencies hardcoded
function getUser() {
  const db = new Database();  // Hardcoded
  return db.query('SELECT * FROM users');
}

// Easy to test: dependency injection
function getUser(db: Database) {
  return db.query('SELECT * FROM users');
}

// Even better: pass interface
interface UserRepository {
  findById(id: string): Promise;
}

function getUser(repo: UserRepository, id: string) {
  return repo.findById(id);
}

    ## Code Review Checklist

    When reviewing code, check for:


      - Does the code do what the PR claims?

      - Are edge cases handled?

      - Is error handling appropriate?

      - Are there tests for new logic?

      - Are names descriptive?

      - Is the code simpler than before?

      - Any security concerns?

      - Any performance issues?



    ## The Boy Scout Rule

    Leave the code a little better than you found it. Every PR is an opportunity to improve the surrounding code slightly:


      - Rename a poorly-named variable while changing the function

      - Extract a magic number while adding new logic

      - Add a missing test while fixing a bug



    Small improvements compound. The codebase gets better over time, not worse.

API Design Best Practices

tiger Z — Tue, 02 Jun 2026 08:56:00 +0000

Published May 26, 2026 · 10 min read · 🏷️ Backend
# API Design Best Practices

    A well-designed API is intuitive, consistent, and developer-friendly. This guide covers the principles and patterns that make APIs a pleasure to use.

    ## Use RESTful Conventions

    REST APIs use standard HTTP methods and URL structures:

GET    /users          # list all users
GET    /users/123       # get single user
POST   /users           # create new user
PUT    /users/123       # update entire user
PATCH  /users/123       # partial update
DELETE /users/123       # delete user

    Key principles:


      - Use nouns in URLs, not verbs (`/users` not `/getUsers`)

      - Use plural nouns consistently

      - Use nested resources for relationships (`/users/123/orders`)

      - Keep URLs lowercase with hyphens



    ## Proper HTTP Status Codes

    Always return the appropriate status code:

200 OK           # successful GET, PUT, PATCH
201 Created       # successful POST creating resource
204 No Content    # successful DELETE
400 Bad Request   # invalid input data
401 Unauthorized  # not authenticated
403 Forbidden     # authenticated but not authorized
404 Not Found     # resource doesn't exist
422 Unprocessable Entity  # validation errors
429 Too Many Requests    # rate limit exceeded
500 Internal Server Error # server error

    ## Consistent Error Format

    Return errors in a consistent structure:

{
  "error": "validation_error",
  "message": "The request body contains invalid data",
  "details": [
    {
      "field": "email",
      "message": "Email format is invalid"
    },
    {
      "field": "password",
      "message": "Password must be at least 8 characters"
    }
  ]
}

    Include enough information for developers to debug, but don't expose sensitive internals.

    ## Pagination

    Don't return unlimited results. Use cursor or offset pagination:

    ### Offset Pagination

GET /users?page=2&per_page=20

# Response
{
  "data": [...],
  "pagination": {
    "page": 2,
    "per_page": 20,
    "total": 150,
    "total_pages": 8
  }
}

    ### Cursor Pagination (Better for Large Datasets)

GET /users?cursor=abc123&limit=20

# Response
{
  "data": [...],
  "pagination": {
    "next_cursor": "def456",
    "has_more": true
  }
}

    Cursor pagination is more efficient for large tables and real-time data.

    ## API Versioning

    Version your API to allow breaking changes without breaking clients:

# URL path (most common)
GET /v1/users
GET /v2/users

# Header approach
Accept: application/vnd.api.v2+json

      **Tip:** Start with v1 even if you don't think you'll need versions. Adding versioning later is harder than starting with it.



    ## Filtering, Sorting, and Field Selection

    Give clients control over their queries:

# Filtering
GET /orders?status=pending&created_after=2024-01-01

# Sorting
GET /products?sort=price&order=desc

# Field selection (sparse fieldsets)
GET /users?fields=id,name,email

# Combining
GET /orders?status=completed&sort=created_at&order=desc&limit=50

    ## Authentication

    Use standard authentication methods:

# API Keys (for server-to-server)
X-API-Key: your-api-key

# Bearer Tokens (for user authentication)
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

# Rate Limiting Headers
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 999
X-RateLimit-Reset: 1640995200

    ## Performance Tips

    ### Response Compression

# Client sends
Accept-Encoding: gzip, deflate, br

# Server responds
Content-Encoding: gzip

    ### Conditional Requests

# Client sends
If-None-Match: "etag-from-previous-response"

# Server checks, returns 304 if unchanged
HTTP/1.1 304 Not Modified

    ### Cache Control

Cache-Control: public, max-age=3600
ETag: "abc123"
Last-Modified: Wed, 01 Jan 2024 00:00:00 GMT

    ## Documentation

    Good API documentation includes:


      - Authentication instructions

      - All endpoints with request/response examples

      - Error codes and messages

      - Rate limits and quotas

      - Try-it-out sandbox



    Use OpenAPI/Swagger for machine-readable specs that generate documentation automatically.

API Authentication Methods Explained

tiger Z — Tue, 02 Jun 2026 08:55:53 +0000

Published May 29, 2026 · 8 min read · 🏷️ Security
# API Authentication Methods Explained

    Authentication is critical for API security. This guide compares the main methods — API Keys, Basic Auth, Bearer Tokens, OAuth 2.0, and JWT — with pros, cons, and when to use each.

    ## API Keys

    Simple static keys assigned to clients:

curl -H "X-API-Key: your-api-key-here" https://api.example.com/data

    **Pros:**


      - Simple to implement

      - Easy to understand and debug

      - Good for server-to-server communication



    **Cons:**


      - No expiration (unless you implement it)

      - If leaked, full access until revoked

      - No granular permissions (all-or-nothing)



    **Best for:** Internal services, simple third-party integrations

    ## Basic Authentication

    Username and password sent with each request (Base64 encoded, not encrypted):

# Encoding: Base64("username:password")
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/

# Or use curl's built-in auth
curl -u username:password https://api.example.com/

    **Pros:**


      - Extremely simple

      - Universally supported

      - Good for testing



    **Cons:**


      - Credentials sent with every request

      - Must always use HTTPS

      - No built-in expiration




      **Never use Basic Auth over HTTP.** Without TLS, credentials are sent in plain text visible to anyone watching network traffic.



    ## Bearer Tokens (Token Authentication)

    A token is issued after authentication and sent with each request:

# After login, server returns token
# Client stores token and sends with requests
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

    **Pros:**


      - Credentials only sent once

      - Token can expire

      - Easier to revoke (delete from database)



    **Cons:**


      - Requires database lookup to validate (unless using JWT)

      - State must be stored server-side



    ## JWT (JSON Web Tokens)

    Self-contained tokens that include the data payload (stateless):

// JWT has three parts: header.payload.signature
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIn0.signature

// Server verifies signature without database lookup
const payload = jwt.verify(token, SECRET_KEY);
console.log(payload.userId);  // 123

    **Structure:**


      - **Header**: Algorithm and token type

      - **Payload**: Claims (userId, role, exp, etc.)

      - **Signature**: Prevents tampering



    **Pros:**


      - Stateless — no database lookup needed

      - Can include user data and permissions

      - Works across services (microservices)



    **Cons:**


      - Can't revoke until expiration (use short expiry + refresh tokens)

      - Payload is visible (don't store sensitive data)

      - Larger than API keys



    ## OAuth 2.0

    A proper authorization framework for third-party access:

# 1. User clicks "Login with Google"
# 2. Redirect to Google with client_id and redirect_uri
GET https://accounts.google.com/o/oauth2/v2/auth?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/callback&
  response_type=code&
  scope=openid%20profile%20email

# 3. Google redirects back with authorization code
# 4. Your server exchanges code for access token
POST https://oauth2.googleapis.com/token
{
  code: "authorization_code",
  client_id: "YOUR_CLIENT_ID",
  client_secret: "YOUR_CLIENT_SECRET",
  redirect_uri: "https://yourapp.com/callback",
  grant_type: "authorization_code"
}

# 5. Response includes access token (and optionally refresh token)
{
  access_token: "ya29....",
  expires_in: 3600,
  refresh_token: "refresh_token_here"
}

    **Grant Types:**


      - **Authorization Code**: Web apps (full flow)

      - **PKCE**: Mobile/SPA apps (no client secret)

      - **Client Credentials**: Server-to-server (no user)

      - **Refresh Token**: Get new access tokens



    ## Comparison Table




          Method
          Complexity
          Best For




          API Keys
          Low
          Simple server-to-server


          Basic Auth
          Low
          Testing, internal tools


          Bearer Tokens
          Medium
          Session-based auth


          JWT
          Medium
          Microservices, stateless auth


          OAuth 2.0
          High
          Third-party login, social auth




    ## Security Best Practices


      - **Always use HTTPS** — never send credentials over HTTP

      - **Use short token expiry** — 15-60 minutes for access tokens

      - **Implement refresh tokens** — allow re-authentication without re-login

      - **Store secrets securely** — environment variables, not in code

      - **Log authentication events** — detect anomalies

      - **Implement rate limiting** — prevent brute force attacks

      - **Rotate secrets** — change API keys periodically

Base64 Encoding Explained: When to Use It and Why It Matters

tiger Z — Tue, 02 Jun 2026 08:54:13 +0000

Base64 is a binary-to-text encoding scheme that converts binary data into ASCII text format. It's everywhere in modern web development — from API responses to inline images — and understanding it will make you a better developer.

  ## What Is Base64 and Why Does It Exist?

  computers store everything as binary data (1s and 0s). But some protocols and systems — like email (SMTP), JSON APIs, and URLs — can only handle text. Base64 solves this by mapping binary data to a set of 64 printable ASCII characters (A-Z, a-z, 0-9, +, and /).

  Imagine you have an image file. You can't put raw binary into a JSON response — it would break the parser. But if you Base64-encode it, you get a string like `R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7` that any system can handle.

  ## How Base64 Works (Step by Step)

  Each 3 bytes of binary data (24 bits) are split into four 6-bit groups. Each group maps to a character in the Base64 alphabet:

Text: "Hi"
Binary: 01001000 01101001
Split into 6-bit groups: 010010 000110 1001--
Pad with zeros:         010010 000110 100100
Base64 indices:         18     6      36     --
Result:                 "S"   "G"    "k"    "=" (padding)

  So "Hi" becomes `SGk=`. The `=` at the end is padding — Base64 works in groups of 4 characters, so input that isn't divisible by 3 gets padded.

  ## When to Use Base64

  ### 1. Inline Images in CSS/HTML

  Instead of loading an external image file, you can embed it directly:

![](data:image/png;base64,iVBORw0KGgo...)

  Use for small icons or images (under 1-2KB) where the HTTP request overhead is larger than the encoded data. Don't use for large images — it inflates file size by ~33% and can't be cached separately.

  ### 2. JSON API Responses

  When transmitting binary data through an API, Base64 is the standard encoding:

{
  "filename": "avatar.png",
  "data": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==",
  "mimeType": "image/png"
}

  ### 3. Embedding Small Files in Configuration

  API keys, certificates, and small files are often Base64-encoded in config files or environment variables to avoid escaping issues with special characters.

  ## Common Use Cases


    - **Email attachments** — MIME encoding for binary attachments in emails

    - **JWT tokens** — Header and payload are Base64URL-encoded

    - **Basic authentication** — Username:password becomes Base64 header

    - **Data URLs** — Embed images directly in HTML/CSS

    - **OAuth tokens** — Many providers return tokens as Base64 strings



  ## Base64 vs Base32 vs Base16

  Base64 uses 64 characters and produces compact output (33% overhead). Base32 uses 32 characters (A-Z, 2-7) and is case-insensitive — useful in DNS environments where case can be lost. Base16 (hex) uses only 16 characters and is easiest to read but produces the largest output.

  ## Try It Yourself

  Use our [Base64 Encoder tool](../../tools/dev/base64-encoder.html) to convert text or images to Base64 instantly. Everything happens locally in your browser — your data never leaves your device.

  ## Security Considerations

  Base64 is **not encryption**. Anyone can decode a Base64 string — it's just encoding, not security. Never store passwords or sensitive data as plain Base64. For data protection, use AES, RSA, or other encryption algorithms.

  However, Base64 is useful for obscuring data from casual observation — similar to "security through obscurity." It's not a substitute for real encryption but can add a layer against casual inspection.

  ## Performance Tip

  Base64 encoding inflates data size by 33%. If you're encoding large files (images over 50KB, documents, archives), consider using binary transfer instead. For small data — tokens, small icons, config values — Base64 is efficient and portable.

HTTP Headers: The Complete Guide for Developers

tiger Z — Tue, 02 Jun 2026 08:52:24 +0000

HTTP headers are the invisible glue that makes the web work. They control caching, enforce security, enable authentication, and shape performance. Most developers only know a handful — this guide covers all the ones that actually matter.

  ## How HTTP Headers Work

  Every HTTP request and response carries headers: key-value pairs that pass metadata between client and server. Headers are divided into four categories:


    - **General** — Apply to both requests and responses (Date, Connection)

    - **Request** — Sent by the client (Accept, Authorization, User-Agent)

    - **Response** — Sent by the server (Content-Type, Cache-Control, Set-Cookie)

    - **Entity** — Describe the body content (Content-Length, Content-Encoding)



  ## Security Headers (Essential)

  These five headers prevent the most common web attacks. Set them on every production site:

  ### Content-Security-Policy (CSP)

  Controls which resources the browser can load. Prevents XSS by specifying allowed sources:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://cdn.example.com; style-src 'self' 'unsafe-inline'

  Start with 'none', then add exceptions as you discover them. Use report-uri to catch violations:

Content-Security-Policy: default-src 'none'; report-uri /csp-violation

  ### X-Content-Type-Options

  Prevents MIME type sniffing. Without this header, browsers might execute files they shouldn't:

X-Content-Type-Options: nosniff

  ### X-Frame-Options

  Prevents clickjacking by controlling whether your page can be embedded in iframes:

X-Frame-Options: DENY  # No embedding allowed
X-Frame-Options: SAMEORIGIN  # Only same-site embedding

  ### Strict-Transport-Security (HSTS)

  Forces HTTPS connections. Browser remembers to only use HTTPS for your domain:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

  Start with a short max-age (like 60 seconds) while testing, then increase. The preload flag lets you submit to the HSTS preload list for maximum protection.

  ### Referrer-Policy

  Controls how much referrer information is sent with requests. Prevents leaking sensitive URLs:

Referrer-Policy: strict-origin-when-cross-origin  # Default for most sites
Referrer-Policy: no-referrer  # Most private option
Referrer-Policy: same-origin  # Only send for same-site requests

  ## Caching Headers

  Proper caching makes your site fast and reduces server load. There are two models:

  ### Expiration Model (Cache-Control)

  Tell browsers how long to cache a resource:

# Cache for 1 year (for versioned/hash files)
Cache-Control: public, max-age=31536000, immutable

# Cache for 1 hour, but allow stale responses while revalidating
Cache-Control: public, max-age=3600, stale-while-revalidate=86400

# Don't cache at all
Cache-Control: no-cache, no-store, must-revalidate

  ### Validation Model (ETag / Last-Modified)

  Check if cached content is still valid without downloading it:

# Server response includes:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

# Next request asks if changed:
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

# Server returns 304 Not Modified if still valid (no body)

  ### Cacheable Responses

  Not everything should be cached. Rules:


    - **GET / HEAD** — Cachable by default

    - **POST / PATCH / PUT / DELETE** — Never cached automatically

    - **Responses with Set-Cookie** — Never cache

    - **Authenticated requests** — Usually private, unless using shared caches



  ## CORS Headers

  Cross-Origin Resource Sharing headers control which domains can access your API:

# Allow specific origin (preferred)
Access-Control-Allow-Origin: https://trusted-app.com

# Allow any origin (for public APIs, combined with Vary: Origin)
Access-Control-Allow-Origin: *

# Preflight request for non-simple methods/headers
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400  # Cache preflight for 24 hours

  Never use `Access-Control-Allow-Origin: *` with credentials (cookies, auth headers):

# Wrong — browsers reject this
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

# Correct — use a specific origin
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

  ## Authentication Headers

  ### Basic Authentication

# Client sends:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
# (Base64 encoded "username:password")

# Server responds 401:
WWW-Authenticate: Basic realm="Protected Area"

  ### Bearer Tokens (JWT, API Keys)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

  ### Custom Headers

  Many APIs use custom headers for authentication:

X-API-Key: your-api-key-here
X-Auth-Token: session-token
Authorization: ApiKey your-api-key

  ## Content Negotiation

  Tell the server what format you want back:

# Accept specific content type
Accept: application/json

# Accept multiple formats (server chooses best match)
Accept: application/json, application/xml, text/html

# Prefer compressed responses
Accept-Encoding: gzip, deflate, br

# Prefer English, but accept Chinese
Accept-Language: en, zh;q=0.9

  ## Performance Headers

  ### Compression

# Server sends compressed response
Content-Encoding: gzip  # or br (Brotli), deflate

# Client advertises supported compression
Accept-Encoding: gzip, deflate, br

  ### Range Requests

  For resumable downloads and video streaming:

# Client requests specific bytes
Range: bytes=0-99

# Server responds with portion
Content-Range: bytes 0-99/total_file_size

  ### Early Hints

  Send resource hints before the full response is ready:

# Early hint response (HTTP 103)
Link: ; rel=preload; as=style

# Followed by final response
103 Early Hint
200 OK

  ## Debugging Headers

  Tools to inspect and test headers:


    - **Chrome DevTools** — Network tab shows all headers

    - **curl -I** — Show response headers only

    - **httpbin.org** — Test headers interactively

    - **securityheaders.com** — Grade your security headers

# View headers with curl
curl -I https://example.com

# Send custom headers
curl -H "Authorization: Bearer token" https://api.example.com

# Show request and response headers
curl -v https://example.com

  ## Minimum Viable Header Set

  Every production site should have at minimum:

Content-Type: text/html; charset=utf-8
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin

  ## Key Takeaways


    - Security headers (CSP, HSTS, X-Frame-Options) prevent common attacks — set them on every site

    - Cache-Control with max-age is simpler than ETag validation for most use cases

    - Use immutable + long max-age for versioned assets (JS, CSS with hashes in filenames)

    - CORS headers should whitelist specific origins, not use * (except for truly public APIs)

    - Always test headers with curl or DevTools before deploying to production




    ← Back to Blog