I’ve also put together a hands-on demo project — demoCORS — that you can clone and run locally to see every concept in action.

1. The Same-Origin Policy (SOP)

Why it exists

The year is 1995. Netscape Navigator 2.0 introduces JavaScript into the browser. For the first time, code running in one browser tab can manipulate the DOM, read form data, and make HTTP requests. Immediately, a problem emerges: if a user has two tabs open — their bank at bank.com and a malicious site at evil.com — the malicious site’s JavaScript could read data from the bank tab.

The Same-Origin Policy was introduced to prevent this. It is the foundational security boundary of the web platform: code from one origin cannot read data from a different origin.

It’s important to understand what SOP does NOT do: it does not prevent requests from being sent. It prevents responses from being read. A page on evil.com can trigger a GET request to bank.com, and that request will arrive at the bank’s server (potentially with cookies). What SOP prevents is evil.com’s JavaScript from reading the bank’s response.

What is an “origin”?

An origin is defined by three components:

Origin = scheme + host + port

Let’s examine concrete examples:

Every single one of these is a different origin:

• Row 1 vs Row 2: different host (example.com vs api.example.com — subdomains are different hosts)
• Row 1 vs Row 3: different scheme (https vs http)
• Row 1 vs Row 4: different port (443 vs 8080)

This is exactly the principle at work in the demoCORS project: http://localhost:3000 and http://localhost:4000 differ in port, making them cross-origin.

What SOP blocks

SOP restricts JavaScript’s ability to read cross-origin responses from:

• fetch() and XMLHttpRequest
• Reading <canvas> pixels painted from cross-origin images
• Accessing contentDocument of cross-origin <iframe>s
• Reading responses from cross-origin EventSource (SSE)

SOP does NOT block:

• <img src="..."> — images load cross-origin (but you can’t read their pixels)
• <script src="..."> — scripts load and execute cross-origin (the origin of JSONP and supply-chain attacks)
• <link rel="stylesheet" href="..."> — stylesheets load cross-origin
• <form action="..."> — forms can submit cross-origin (the origin of CSRF attacks)
• <iframe src="..."> — iframes load cross-origin (but parent can’t read content)

2. Why CORS Exists

SOP was designed for a 1990s web where pages were self-contained documents. The modern web is fundamentally different:

• Single-Page Applications (SPAs) serve a static frontend from app.example.com and call APIs at api.example.com
• Microservices expose multiple APIs on different domains or ports
• Third-party integrations require calling payment processors, analytics services, CDNs
• Development environments run frontends and backends on different ports (exactly like demoCORS: port 3000 and port 4000)

Without any mechanism to relax SOP, none of these architectures would work. You’d be forced to same-origin-proxy every API call through your frontend server.

CORS (Cross-Origin Resource Sharing) is that mechanism. It is a protocol — a set of HTTP headers — that allows a server to declare: “I trust requests from these specific origins.”

The key insight is: CORS is not a way to add security. It’s a controlled way to remove a security restriction. SOP is the default. CORS is the opt-out.

3. CORS Request Types

The CORS specification divides cross-origin requests into two categories based on their potential to cause side effects.

Simple Requests

A request is “simple” (formally a request that doesn’t trigger a preflight) when ALL of these conditions are met:

Method is one of:

• GET
• HEAD
• POST

Headers are limited to the CORS-safelisted set:

• Accept
• Accept-Language
• Content-Language
• Content-Type (with restrictions, see below)
• Range (with restrictions)

Content-Type (if present) is one of:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

No ReadableStream body is used. No event listeners are registered on the XMLHttpRequest.upload object.

Why these conditions? Because a simple request is no more dangerous than what an HTML <form> can already do. Forms can POST with application/x-www-form-urlencoded or multipart/form-data to any URL. SOP never blocked form submissions. So a “simple” CORS request adds no new attack surface — the browser just needs to check whether the server wants the response shared.

In the demoCORS project, the fetch() calls are simple GET requests with no custom headers:

await fetch("http://localhost:4000/api/data");

This meets all simple request criteria, so no preflight occurs.

Preflighted Requests

Any request that doesn’t meet the “simple” criteria triggers a preflight. Common triggers include:

• Methods: PUT, DELETE, PATCH
• Headers: Authorization, X-Custom-Header, any custom header
• Content-Type: application/json

Before sending the actual request, the browser sends an OPTIONS request asking the server: “Will you accept this kind of request?”

The reason for preflight is safety: methods like DELETE or headers like Authorization can cause side effects on the server. The browser needs to verify the server actually expects these cross-origin requests before sending them, because unlike simple requests, these operations couldn’t be triggered by a plain HTML <form>.

Full HTTP Flow — Preflighted Request

Scenario: A frontend at https://app.example.com sends a JSON POST to https://api.example.com.

Step 1: Preflight Request (Browser → Server)

OPTIONS /api/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

Step 2: Preflight Response (Server → Browser)

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: content-type, authorization
Access-Control-Max-Age: 86400

Step 3: Actual Request (Browser → Server)

POST /api/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

{"name": "Karan", "role": "Developer"}

Step 4: Actual Response (Server → Browser)

HTTP/1.1 201 Created
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json

{"id": 42, "name": "Karan", "role": "Developer"}

If the preflight response at Step 2 were missing authorization in Access-Control-Allow-Headers, the browser would never send Step 3. The actual request is completely blocked before it leaves the browser.

4. CORS Request Flow — Step by Step

Here’s the complete decision tree the browser follows for every fetch() call:

JavaScript calls fetch(url, options)
         │
         ▼
┌─────────────────────────┐
│ Is the target origin the │
│ same as the page origin? │
└───────┬─────────┬────────┘
        │ Yes     │ No
        ▼         ▼
  [Normal HTTP  ┌──────────────────────┐
   request,     │ Is this a "simple"   │
   no CORS]     │ request?             │
                └──────┬────────┬──────┘
                       │ Yes    │ No
                       ▼        ▼
               [Send request  [Send OPTIONS
                directly with  preflight first]
                Origin header]       │
                       │             ▼
                       │      ┌───────────────────┐
                       │      │ Does preflight     │
                       │      │ response approve?  │
                       │      └──┬──────────┬──────┘
                       │         │ Yes      │ No
                       │         ▼          ▼
                       │    [Send actual  [Block. TypeError
                       │     request]      in JavaScript]
                       │         │
                       ▼         ▼
               ┌───────────────────────┐
               │ Does response contain │
               │ valid CORS headers?   │
               └──────┬─────────┬──────┘
                      │ Yes     │ No
                      ▼         ▼
              [Expose response  [Block response.
               to JavaScript]   TypeError in
                                JavaScript]

The critical misconception

CORS does not prevent the request from reaching the server. It only controls whether the browser exposes the response to JavaScript.

For simple requests, the server always receives and processes the request. The Origin header is present, but the server responds normally. Only then does the browser decide whether to hand the response to JavaScript.

This means CORS is not a substitute for server-side authorization. If your server processes a DELETE /api/users/42 and only then sends back a response missing CORS headers, the record is already deleted — the browser just won’t show the confirmation to the attacker’s JavaScript.

For preflighted requests, the protection is stronger: the browser’s OPTIONS preflight happens first, and if it fails, the actual DELETE is never sent. But you should never rely on preflight as your security boundary.

5. Preflight Mechanism — Deep Dive

The OPTIONS request

When a browser determines that a request requires preflight, it constructs an OPTIONS request automatically. JavaScript code has no control over this — no ability to modify, suppress, or intercept the preflight.

Example preflight request:

OPTIONS /api/data HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

Key headers:

• Origin: The requesting page’s origin (always present)
• Access-Control-Request-Method: The HTTP method the actual request will use
• Access-Control-Request-Headers: The non-safelisted headers the actual request will include

Expected server response

The server must respond to the OPTIONS request with:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Max-Age: 86400

What happens when headers are missing

Preflight caching

Access-Control-Max-Age tells the browser how many seconds to cache the preflight result. During that window, subsequent requests to the same URL with compatible methods and headers skip the OPTIONS check entirely.

Without caching, every single API call generates two HTTP requests — a significant performance tax. In the demoCORS project, Max-Age is not configured, meaning every preflight is re-sent. In production, values of 86400 (24 hours) or 3600 (1 hour) are typical.

Note: Browsers impose their own maximum. Chrome caps at 7200 seconds (2 hours), regardless of what the server sends.

6. CORS Headers Explained — In Depth

Access-Control-Allow-Origin

Purpose: The single most important CORS header. Declares which origin(s) may read the response.

Valid values:

• * — Any origin (but cannot be used with credentials)
• https://specific-origin.com — Exactly one origin
• (There is no native support for multiple origins in a single header value)

The multiple-origin problem: You cannot write:

Access-Control-Allow-Origin: https://a.com, https://b.com   ❌ INVALID

The spec only allows a single origin or *. To support multiple origins, the server must:

1. Read the Origin request header
2. Check it against an allowlist
3. If approved, reflect that specific origin in the response
4. Set Vary: Origin to prevent cache poisoning

This is exactly what the cors npm middleware does when given an array or function for the origin option.

Edge case: If the server sets Access-Control-Allow-Origin: null, the browser will match it against the null origin (used by sandboxed iframes, file:// URLs, and redirected requests). This is dangerous because an attacker can craft a sandboxed iframe with Origin: null and exploit this match.

Access-Control-Allow-Methods

Purpose: Sent only in preflight responses. Lists the HTTP methods the server accepts.

Note: For simple requests (GET, HEAD, POST), this header is not checked — the browser already knows those methods are inherently acceptable at the CORS level.

Example:

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH

Access-Control-Allow-Headers

Purpose: Sent only in preflight responses. Lists the request headers the server accepts beyond the CORS-safelisted set.

Example:

Access-Control-Allow-Headers: Authorization, Content-Type, X-Request-ID

Important: As of the 2023 Fetch specification, * is a valid value for this header (and Access-Control-Allow-Methods), meaning “all headers/methods are allowed.” However, this wildcard does not apply when credentials: true — in that case, every header must be explicitly listed.

Access-Control-Allow-Credentials

Purpose: Tells the browser to include cookies, Authorization headers, and TLS client certificates in cross-origin requests.

The cardinal rule:

When Access-Control-Allow-Credentials: true is set, Access-Control-Allow-Origin MUST NOT be *.

Browsers enforce this strictly. If a server sends both Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true, the browser rejects the response. This prevents a server from accidentally exposing authenticated data to every site on the internet.

Client side: The fetch() call must also opt in:

fetch(url, { credentials: "include" });

Without credentials: 'include', the browser won’t send cookies even if the server allows them.

Access-Control-Max-Age

Purpose: Duration (in seconds) the browser may cache the preflight response.

Example:

Access-Control-Max-Age: 86400

Browser limits:

• Chrome: max 7200 (2 hours)
• Firefox: max 86400 (24 hours)
• Safari: max 604800 (7 days)

Access-Control-Expose-Headers

Purpose: By default, JavaScript can only access these response headers: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Pragma. All other headers are hidden.

To expose custom response headers (e.g., X-Request-ID, X-RateLimit-Remaining), the server must include:

Access-Control-Expose-Headers: X-Request-ID, X-RateLimit-Remaining

7. Credentials and Cookies

The problem

By default, fetch() does not send cookies or auth headers cross-origin. To include them:

Client:

fetch("https://api.example.com/me", {
  credentials: "include", // Send cookies cross-origin
});

Server must respond with:

Access-Control-Allow-Origin: https://app.example.com  (NOT *)
Access-Control-Allow-Credentials: true

Why * cannot work with credentials

If Access-Control-Allow-Origin: * were allowed with credentials, any website could:

1. Make a credentialed request to your API
2. The browser would send the user’s cookies
3. The * would allow any origin to read the response
4. The attacker reads authenticated data

This is why browsers enforce the rule: wildcard + credentials = rejected.

How SameSite cookies interact

Modern browsers also enforce SameSite cookie attributes:

• SameSite=Strict: Cookie is never sent cross-site
• SameSite=Lax: Cookie sent only for top-level navigations (GET), not for fetch()
• SameSite=None; Secure: Cookie is sent cross-site (required for CORS with credentials)

Even if CORS is correctly configured, a cookie with SameSite=Lax won’t be included in a cross-origin fetch(). The cookie must be SameSite=None; Secure.

8. Common CORS Misconfigurations

1. Origin Reflection Without Validation

app.use((req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", req.headers.origin);
  res.setHeader("Access-Control-Allow-Credentials", "true");
  next();
});

This reflects whatever origin the request sends. Combined with credentials, an attacker at evil.com can:

• Make a credentialed request to your API
• Your server reflects evil.com as the allowed origin
• The browser sends cookies and allows evil.com to read the response
• Result: full data exfiltration

Severity: Critical

2. Null Origin Allowance

cors({ origin: "null" }); // or checking req.headers.origin === 'null'

The null origin can be crafted via:

• Sandboxed iframes: <iframe sandbox="allow-scripts" src="data:text/html,...">
• file:// URLs
• Cross-origin redirects

An attacker embeds their exploit in a sandboxed iframe, which sends Origin: null, and the server approves it.

3. Regex Mistakes

cors({ origin: /example\.com/ });

This matches malicious-example.com, example.com.evil.com, etc. The regex is not anchored.

Correct:

cors({ origin: /^https:\/\/([a-z]+\.)?example\.com$/ });

4. Pre-domain Matching

const allowed = ['https://app.example.com'];
const origin = req.headers.origin;
if (allowed.some(a => origin.includes(a))) { ... }

An attacker registers https://app.example.com.evil.com — the includes() check passes.

Correct approach: Use exact string matching or properly anchored regexes.

5. Wildcard Subdomain Trust

cors({ origin: /^https:\/\/.*\.example\.com$/ });

This trusts every subdomain. If any subdomain has an XSS vulnerability (say, user-content.example.com), the attacker can leverage that XSS to make credentialed requests from a trusted origin.

9. CORS vs Other Browser Protections

CORS vs CSRF

CORS does not prevent CSRF. A form submission or a simple POST from an attacker’s site will reach your server regardless of CORS settings. You need CSRF tokens or SameSite cookies separately.

CORS vs CORB (Cross-Origin Read Blocking)

CORB is a browser-side defense (introduced in Chrome 68) that blocks certain cross-origin responses from even entering the renderer process — before CORS checks. It protects against Spectre-style side-channel attacks.

If a <script> tag requests an HTML or JSON resource cross-origin, CORB strips the body entirely, preventing even a Spectre attack from reading it from memory.

CORB is transparent and automatic. It does not replace CORS — it adds defense-in-depth.

CORS vs CSP (Content Security Policy)

They protect from opposite directions. CSP says “I restrict what my page can do.” CORS says “I restrict who can read my responses.”

Interaction

In a well-configured system:

• CSP prevents XSS by restricting script sources
• CORS prevents data theft by restricting response access
• SameSite cookies prevent CSRF by restricting cookie sending
• CORB prevents side-channel data leaks

These are layers of a defense-in-depth strategy, not alternatives to each other.

10. Practical Debugging

Browser DevTools — The CORS Debugging Workflow

Step 1: Open Network Tab Open DevTools (F12) → Network tab → reproduce the request.

Step 2: Look for the OPTIONS request If preflight is involved, you’ll see two requests:

1. OPTIONS /api/data — the preflight
2. GET /api/data (or POST, etc.) — the actual request

If only the OPTIONS appears and the actual request is missing, the preflight failed.

Step 3: Inspect the preflight response headers Click the OPTIONS request and check Response Headers:

Access-Control-Allow-Origin: https://app.example.com   ← present?
Access-Control-Allow-Methods: GET, POST                 ← includes your method?
Access-Control-Allow-Headers: Authorization              ← includes your headers?

Step 4: Check the Console Chrome provides detailed CORS error messages:

Access to fetch at 'http://localhost:4000/api/data' from origin
'http://localhost:3000' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.

Step 5: Common mistakes to check

• Is the Origin being sent? (Check request headers)
• Is the server responding with the correct Access-Control-Allow-Origin?
• Is there a redirect? (Redirects during CORS can fail)
• Are credentials being sent? (Check if Access-Control-Allow-Credentials: true is present)
• Is the status code 200/204 for the preflight? (Some servers return 403 for OPTIONS)

Step 6: curl to isolate client vs server Test from the command line to determine if it’s a server configuration issue:

curl -v -X OPTIONS \
  -H "Origin: http://localhost:3000" \
  -H "Access-Control-Request-Method: GET" \
  http://localhost:4000/api/data

If the response includes correct CORS headers, the server is fine — the issue is in the browser-side code. If not, the server needs fixing.

11. Real-World Deployment Patterns

Node.js / Express

The demoCORS project uses the cors npm package, which is the standard for Express:

const cors = require("cors");

// Production configuration
app.use(
  cors({
    origin: ["https://app.example.com", "https://staging.example.com"],
    methods: ["GET", "POST", "PUT", "DELETE"],
    allowedHeaders: ["Content-Type", "Authorization"],
    credentials: true,
    maxAge: 86400,
  })
);

Common mistake: Using cors() with no options (allows *), then wondering why credentials don’t work.

Nginx

CORS is frequently handled at the reverse proxy level:

server {
    location /api/ {
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' $http_origin;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
            add_header 'Access-Control-Allow-Credentials' 'true';
            add_header 'Access-Control-Max-Age' 86400;
            return 204;
        }

        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;

        proxy_pass http://backend;
    }
}

Common mistakes:

• Forgetting the always directive (headers are not sent on error responses like 500)
• Using $http_origin without validation (origin reflection vulnerability)
• Not handling OPTIONS separately (the proxy forwards it to the backend, which may return 404)

Cloud APIs (AWS API Gateway)

AWS API Gateway has built-in CORS support:

• Configured per endpoint via console or CloudFormation/SAM
• Automatically generates OPTIONS responses
• Easy to misconfigure by enabling “allow all origins” during development and forgetting to restrict in production

Common mistake: Setting Access-Control-Allow-Origin: * on API Gateway and adding Authorization headers. This works without credentials but breaks when credentials: 'include' is added.

API Gateways (Kong, Envoy, Traefik)

Most API gateways provide CORS as a plugin or middleware:

# Kong CORS plugin
plugins:
  - name: cors
    config:
      origins:
        - https://app.example.com
      methods:
        - GET
        - POST
      headers:
        - Authorization
        - Content-Type
      credentials: true
      max_age: 86400

Advantage: CORS is handled at the edge, and individual microservices don’t need to implement it.

Risk: If the gateway handles CORS but a microservice also adds CORS headers, you get duplicate headers — and browsers may reject responses with multiple Access-Control-Allow-Origin values.

Summary of Common Deployment Mistakes

Conclusion: A Mental Model for CORS

CORS is often perceived as an obstacle — an annoying error that appears in the console during development. But understanding it deeply reveals that it is an elegantly simple protocol:

1. The browser is the enforcer. Not the server, not JavaScript — the browser’s security engine.
2. The server is the policy declarer. It communicates trust via response headers.
3. JavaScript is the subject. It can initiate requests but has no power to override CORS.
4. CORS protects the response, not the request. The server always receives the request (except when preflight fails).
5. Preflight is an optimization for safety. It prevents dangerous requests from being sent, not just their responses from being read.

When you encounter a CORS error, the debugging approach is mechanical:

1. What is my origin?
2. What origin does the server allow?
3. Do they match?
4. Am I triggering preflight? Does the server handle OPTIONS?
5. Am I sending credentials? Is the server configured for credentials?

If you can answer these five questions, you can debug any CORS issue.

Try It Yourself

Clone the demoCORS project to see these concepts in action:

git clone https://github.com/karankessy/demoCORS.git
cd demoCORS
npm install
npm start

Open http://localhost:3000 and watch the Network tab in DevTools to see CORS headers and preflight requests in real time.

Further Reading

• MDN — Cross-Origin Resource Sharing (CORS)
• Fetch Standard — CORS Protocol
• web.dev — Cross-Origin Resource Sharing
• PortSwigger — CORS Misconfigurations
• OWASP — CORS Cheat Sheet

F5 BIG-IP is a good of a solutions when it comes to Web Application Firewall and Load Balancing tasks. I’ve been working with it for over half and a year now — it does its job quite well, protecting applications through real time traffic inspection and respective response enforcement. But it comes with a very real limit when it comes to local log storage at least in this series of F5 WAF which is claimed to be fixed in newer product series. On virtual editions, it caps at 3 million records or 2 GB of database space; on physical systems, it goes to 5 GB.

I often get surprised when I find people getting disappointed over F5 not storing logs for much longer time. It is a limit but not really a flaw — it is so by design. WAF’s main job is to process live traffic and respond to attacks instantly & accordingly. Storing, indexing, and searching logs is whole another world — slow, storage-hungry, and heavy on CPU. If F5 did all that itself, it would steal power from what it’s best at: stopping attacks as they happen. That’s why offloading logs & events to a SIEM is all that makes sense & that is why it is made for.

Expecting a single product to be both a WAF and a SIEM is like asking a Formula 1 car to tow a truck—technically possible, but you’ll burn the engine before the truck moves.

And that is where Wazuh comes in.
F5 does it all to guard the gate, Wazuh keeps the records. It collects logs, parses them into useful fields, stores them for months or years depends how rich you are, and even alerts you when something suspicious happens. It understands CEF, and so does F5 if you set it to ArcSight mode. On paper, this pairing looked simple.

The Eighteen-Month Standoff

The documentation looked simple enough:

• Both systems support syslog.
• Both understand CEF.
• A few settings on each side, and done.

But the reality wasn’t so generous. Find my issue here: #27392

I tried buffer tweaks, IP changes, subnet shuffles, protocol switches, even manual rsyslog in the middle, even version downgrades. Sometimes some part of logs came through fine but just chunked in half, sometimes as hex garbage, sometimes not at all. One day a config would work, the next it was dead for no reason I could find.

And the Breakthrough

And then, one day, no more drama — it just worked.
Maybe Wazuh’s updates fixed something. Maybe my setup finally clicked. Or maybe, after all that time, the stars just lined up. I’m really unknown what is that miracle that made it work this time. It was the most basic configuration I did, which I had repeated maybe dozens of times 18 months before.

Anyways, moving onwards with the newly-wed couples.

Step 1 – Create the F5 Logging Profile
In F5:

• Go to Security → Event Logs → Logging Profiles
• Give it a name
• Select the category to log (for me: Application Security)
• Check Storage Destination → Remote Storage
• Use TCP protocol for bigger payloads
• Add your Wazuh receiver’s IP and listening port

Step 2 – Attach to Virtual Server
In Local Traffic → Virtual Servers, pick your target server.
Attach the LOG-WAZUH profile under Security → Policies.
That’s what makes the logs actually leave F5.

Step 3 – Configure Wazuh
In ossec.conf, allow the IP that F5 uses to send logs.
That IP is the external self IP on F5.

To find it:

• Go to Network → Self-IPs → External Self IPs
• Or in the F5 CLI:

ip route get 192.168.180.242 # (Wazuh receiver IP)

The output shows the sending IP — use that in Wazuh’s config.

Restart Wazuh, and it’s ready to receive logs.

Seeing the results

I opened the Wazuh dashboard — and there they were. Clean, parsed CEF logs from F5, showing (fields are yet to have their naming ceremony, never mind):

After eighteen months of silence, they were finally speaking.

Then I hit my DVWA with some test payloads.

XSS it a bit

Command Injection

An alternative path

For high-volume production environments, F5 offers High Speed Logging (HSL) which is faster and more flexible than standard syslog. That’s a bigger story for another time; detailed guidance lives here: Remote HSL for F5 BIG-IP.

And the Lessons from the Journey

Just grace actually, but to know a thing is; each tool sticks to what it does best:

• F5 – live traffic analysis and blocking
• Wazuh – storing, indexing, and digging through logs later

Now, logs flow from F5 to Wazuh in real time. I can check months of history without worrying about F5’s storage limits.

As I write this, logs keep coming in, each one like a little postcard from F5 saying, “I caught something. Thought you should know.”

It took eighteen months for them to talk. But now they do.

Maybe it was an update, maybe a coincidence, at least my ego is not letting I was mistaken as I’ve almost given 1 month trying all the ways I could — or maybe machines just have their moods too.

Nothing mystical about it, but after enough retries, even logic seems to respond better when you stop arguing with it.
This time, it simply worked. And that was enough.

• Be a part of Wazuh Ambassadors Program, if you believe you’re a good fit: https://wazuh.com/ambassadors-program/

But JSON wasn’t made for large language models. It carries a lot of unnecessary baggage: curly braces, commas, extra spaces. All those were required for programmatic purposes, proper formatted so that it could be indexed properly, parsed properly, read properly & play with all the kinds of logic we want. It help human eyes and programs, but for models they just take up too much tokens.

And the problem is when you send JSON to an LLM, every character is a token. Each bracket be in starting-ending, each newline, each comma adds to your token count. That means higher cost, higher processing time, higher CO2 consumption and what not.

Taking this as an example:

{
  "user_id": 123,
  "email": "heisenberg@gmail.com",
  "active": true
}

The data’s clear, but the format is heavy, redundant characters are too much. For models, all the extras waste tokens.

And now what TOON (Token-Oriented Object Notation) does is, it just strips out what large language models don’t need, unnecessary curly braces, commas, extra spaces. It just keeps the data, drops the noise.

Like this:

user_id:123,email:heisenberg@gmail.com,active:true

With this you allegedly reduce 40-60% of the tokens. Things run faster. It costs less to process, keeps your pocket warm & also CO2 control, much needed one.

But the problem is, TOON works best on flat JSON data. If your JSON is nested—one object inside another—flatten it first. If you don’t, TOON can make things worse. You’ll use more tokens; likely 20-30% more, not fewer.

So, we have turn this (Nested JSON):

{
    "user"
        {
            "id":123,
            "email":"heisenberg@gmail.com"
        }
}

To this (Flat Normalized JSON):

{
  "user.id": 123,
  "user.email": "heisenberg@gmail.com"
}

You can make use of JSON normalizer packages if available for the respective programming languages. Then only, the TOON gives you the benefit.

Thus, we have to make use of TOON when it fits:

• JSON is flat or you can flatten it, either manually or via normalizers.
• Token costs matter.
• You’re optimizing for models—not humans.

And hence, If you are in need of human readability, stick with JSON. If your JSON structure is deeply nested and you can’t flatten it due to some complexities, TOON may not help.

Which is why it asks us to measure the difference and then only test on our own data or make use of it.

The point is simple. Better performance, lower cost, less waste. No drama. No buzzwords.

And that’s how we tune and optimize systems to run and not just compile go, not knowing if it is the function or the disease running it.

Know more in detail: TOON Github

1. Host-Based Routing

Host-based routing, also known as VHOST (Virtual Host) routing, is a pattern where multiple domain names point to the same server or endpoint. This approach is particularly useful for managing multiple services under different domains while utilizing the same infrastructure.

Key Features:

• Multiple domains (e.g., server.web.site.com and api.site.com) can point to the same endpoint
• Uses the publicly available IP address
• Ideal for microservices architecture
• Enables efficient resource utilization

2. Path-Based Routing

Path-based routing has gained significant popularity, especially with the rise of container orchestration and ingress controllers. This pattern focuses on the URI portion of the HTTP request to determine where the traffic should be directed.

Example:

http://api.example.com/getprofile/v1/123456
                      └──────────────────┘
                            path

Benefits:

• Granular control over request handling
• Excellent for versioning APIs
• Simplified container scaling
• Enhanced flexibility in microservices architectures

3. Header-Based Routing

The third crucial pattern involves routing based on HTTP headers. While this includes cookie-based persistence, it’s important to note that the Host header is typically excluded from this category since it falls under host-based routing.

Important Considerations:

• Cookie-based persistence for session management
• Custom headers for routing decisions
• Distinct from Host header routing
• Useful for A/B testing and feature flagging

Best Practices

When implementing these routing patterns, consider:

• Using HTTPS for secure communication
• Implementing proper error handling
• Setting up monitoring and logging
• Ensuring scalability in your routing configuration

Conclusion

Understanding these three routing patterns is essential for building better web applications. Each pattern serves specific use cases, and often, a combination of these patterns provides the most effective routing strategy for complex applications.

Recently, Docker announced the integration of WebAssembly (WASM) technology in a technical preview. This news has sparked many questions in the developer community. Some even wonder if WASM might one day replace Docker or other container technologies.

In this blog post, we’ll explore what WebAssembly and Docker are, compare their key features, and look at how they might work together in the future.

What is WebAssembly?

Imagine being able to run a complex desktop application like Photoshop or Figma directly in your web browser—no downloads or installations required. That’s one of the exciting promises of WebAssembly.

• Easy to Understand:
  WebAssembly is a new type of code that lets you run applications built in languages like C, C++, or Rust right in your browser. It works alongside HTML, CSS, and JavaScript, making it possible to bring powerful, high-performance applications online.

• How It Works:
  Normally, desktop programs need to be compiled into machine code that your computer can understand. With WASM, developers compile their code into a special binary format that runs quickly and securely in the browser. Tools like Emscripten help convert C programs into WASM files that can run seamlessly online.

WASM Outside of Browsers

WASM isn’t just for web pages—it can also run on any system that supports a WASM runtime. Think of these runtimes like the engines that let your computer run programs written in other languages (such as the Java Virtual Machine or Python’s interpreter).

• Portability:
  WASM binaries are designed to be platform-neutral. This means they can run on different operating systems and processor types without needing major changes.

• System Access:
  Using the WebAssembly System Interface (WASI), WASM modules can access files, directories, and other system resources. This ability makes it similar to how containers work.

What is Docker?

Docker is a popular technology that packages your application code along with all its dependencies into a single container. This container can run anywhere—on any computer or server—without worrying about differences in operating systems or installed libraries.

• The Problem It Solves:
  Think about how many steps are involved in running a simple C program: installing the right compiler, managing libraries, and setting system paths. Docker simplifies this by bundling everything into one neat package. Now, your colleague on a different system can run your program without any setup headaches.
• How It Works:
  A Docker container uses a Docker image—a snapshot of a file system with all necessary tools, libraries, and your application. When you run the container, it behaves like a small, self-contained computer.

Docker vs WebAssembly: Key Comparisons

While Docker and WASM both help package and run applications, they work in different ways:

• Architecture:
  • Docker: Packages the entire file system, dependencies, and binaries into a container.
  • WASM: Creates a compact, precompiled binary. WASI then supplies the system resources at runtime.
• Portability:
  • Docker: Requires matching the image with the right operating system and processor type.
  • WASM: Works across platforms, independent of the underlying hardware.
• Performance & Size:
  • Docker: Containers can be tens or hundreds of megabytes and may take seconds to start.
  • WASM: Modules are only a few megabytes and start in milliseconds, offering near-native performance.
• Usage Scenarios:
  • Docker: Best for packaging full applications with all their dependencies in a controlled environment.
  • WASM: Ideal for running high-performance code on the web or in other environments where quick startup is crucial.

Will WASM Replace Docker?

There has been some speculation that WASM could eventually replace Docker, Kubernetes, and other container technologies. However, it’s more likely that WASM will work alongside Docker rather than replace it completely.

• Integration Potential:
  Docker’s recent technical preview shows that you can now run WASM containers alongside traditional Linux and Windows containers. This integration means you could use the fast startup and small size of WASM while still taking advantage of Docker’s powerful container management features.
• Real-World Impact:
  Combining these two technologies could lead to even more efficient, scalable, and secure web applications. Developers might soon enjoy the best of both worlds: Docker’s ease of deployment and WASM’s performance benefits.

Conclusion

Both Docker and WebAssembly offer unique strengths:

• Docker provides a reliable way to package and run full applications in any environment.
• WebAssembly delivers fast, secure execution with impressive portability, especially for web-based applications.

Their integration points toward a promising future where developers can leverage the speed and efficiency of WASM together with the robust ecosystem of Docker. As technology evolves, the blend of these innovations could reshape how we build and deploy software.

What Do Mutable and Immutable Mean?

• Mutable means changeable. Data types like lists, sets, and dictionaries can be modified after they are created.
• Immutable means unchangeable. Data types like strings, integers, and tuples cannot be altered once they are created.

Now, here’s where it gets interesting: even if a data type is immutable, it doesn’t mean you can’t assign new values to a variable. Let’s go a bit further.

Example 1: Strings Are Immutable

>>> username = "karan"
>>> username
'karan'
>>> username = "notkaran"
>>> username
'notkaran'

Strings are immutable, so when you assign a new value to the variable username, Python doesn’t overwrite the old value. Instead:

1. A new memory block is created for the new value "notkaran".
2. The variable username is updated to reference this new block.
3. The old value "karan" is left behind and will be deleted later by Python’s garbage collector, but only if no other variable is using it.

Memory Allocation Diagrams

when username = “karan”

after re-assigning the value when username = “notkaran”

Here, the value "karan" is stored at a different memory location, which will be removed by the garbage collector in Python since no variable is referencing it.

Example 2: Integers and Memory Allocation

>>> x = 10
>>> y = x
>>> x = 20
>>> x
20
>>> y
10

In this case:

• Initially, x and y both reference the same value 10 in memory.
• When you assign 20 to x, Python creates a new memory block for 20 and updates x to reference this new block.
• The value 10 is still in memory because y is referencing it.

Memory Allocation Diagram

In this case, the value 10 won’t be deleted as it is being referenced by y.

Why Does This Matter?

The distinction between mutable and immutable types is crucial for Performance as Immutable objects are often faster because they don’t need mechanisms to handle changes. And Data Safety is another reason as Immutable types prevent accidental modifications, making them ideal for constants and keys in dictionaries.

The Core Engineering Behind Mutability

At the heart of Python’s design lies its memory management system and here is how it works:

• Mutable types like lists and dictionaries store data in a memory buffer that can be altered directly.
• Immutable types don’t allow changes to the data in memory. Instead, new memory is allocated for any modifications.

I didn’t explain much with examples and diagrams about mutability as it is quite easy and obvious after knowing immutability. This ability to allocate new memory or update existing memory is what makes mutability possible (or impossible) at its core.

Critical thinking means giving a fair and unbiased opinion of something, where being critical and thinking critically are not the same thing.

If critical thinking were simply about making judgments, then anyone could do it by giving an opinion without any special training or practice. For instance, if I come across any debates, I may react impulsively based on my preconceived notions, biases and emotions without engaging in critical thinking to evaluate the information presented. This can lead to individuals reacting differently to the same information based on their personal biases and emotional responses.

Taking a hypothetical situation into play, if I watch a film and think that it is boring, even though it has had good reviews, no one can really say that my judgement is wrong and the professional critics are right. Someone can disagree with me, but that is just another judgement, no better or worse, you might say, than mine. In a limited sense, this is true. But a serious critical judgement is more than just a statement of preference or taste. A critical judgement must have some basis, which usually requires a measure of knowledge or expertise on the part of the person making the judgement. Just saying “I like it” or “I don’t like it” is not enough. There have to be some grounds for a judgement before we can call it critical.

And that very ground may start with the proper reason following the conclusion/judgement whether that might be an argument, claims, assertions or statements. Every judgement needs some legit grounds to be considered as a sound or critical judgement.

Critical judgement of any situation firstly starts with the identification of its elements especially premises, also called reasons and the conclusion followed by the reasons. These are the very basic elements to be considered but it is not that easy as it sounds like. Sometimes, judgement might go wrong even after the proper identification of the elements of an argument or a claim and that’s what decides the level of the critical thinking applied or used during the judgement formation.

Before judging any arguments, claims or assertions we need to know what is the exact difference between them. So, arguments are especially interesting because their primary purpose is to persuade or influence people in favor of some claim. The critical question therefore becomes whether the argument succeeds or fails: whether we should allow ourselves to be persuaded by it, or not.

‘Assertion’ and ‘claim’ are very close in meaning. The difference is in when you use them. Assertion’ is a bit stronger and more emphatic; it is more active. A claim may be asserted, but we would not naturally say that an assertion was claimed.

Claims are presented as expressions of truth, yet they are not always true. And critical thinking is a way of being as sure as possible about which claims to believe, and which to question or mistrust. Also, arguments consist of claims: reasons, conclusions, etc.

Analyzing Argument

Example 1

Top women tennis players used to grumble that their prize money was less substantial than that paid to top male players in the same competition. They argued that they were being unequally treated. But the disparity was entirely justified and should never have been abolished. Male players just have more prowess than women. They need to win three sets out of five to take the match; the women only two. They have to play harder and faster, and expend far more energy on court than the women. But most of all, if the best woman in the tournament played any of the men, there would be no contest: the man would win.

As mentioned before, when looking at an argument, the first things to consider are the reason and the conclusion. According to the rule, the first two sentences of the argument [1] do not function as reasons or conclusions but rather set the context for the argument(Try reading the passage without them and you will see this for yourself). Without these sentences, the argument would lack coherence. Such sentences are often referred to as the target or context of the argument.

The purpose of the argument is to respond to the alleged claim of unfairness and inequality by women. Some may refer to parts of a text that serve as the target of an argument as a counter-argument, but this is misleading. If anything, the author’s argument should be considered the counter-argument, since the author is the one responding, not the women.

In standard form, the argument can be represented as follows: Context (or target): Top women tennis players used to complain about the inequalities of prize money.

In the diagram, R1 to R3 represent the reasons, IC is the intermediate conclusion, followed by the reasons R1 to R3, and the main conclusion (MC) is C, which is the main point of the argument, supported by all the reasons and intermediate conclusion (IC).

Now let’s visualize the argument in a diagram:

R1 & R2 —> IC —> [C] <— R3

In the diagram, R1 to R3 represent the reasons, IC is the intermediate conclusion, followed by the reasons R1 to R3, and the main conclusion (MC) is C, which is the main point of the argument, supported by all the reasons and intermediate conclusion (IC).

R1 and R2 are the actual supporting reasons for the intermediate conclusion (IC). These three elements could be a separate argument on their own, but there is another missing argument, R3, which is an independent reason following the main conclusion C.

It is important to note that credible research should support the reasons presented in the argument. For instance, is it true that men have to win three out of five sets while women only need to win two, as stated in R1? Therefore, research should support all the reasons presented, and at least one reason should be true for the argument to be sound. Finally, the main conclusion should be supported by all the IC and reasons presented, or it will make no sense. For example:

The weather has been really nice lately. So, we should invest in renewable energy.

Here,

R1 –> “The weather has been really nice lately”

does not follow the conclusion,

C –> “So, we should invest in renewable energy.”

Thus, the conclusion of an argument needs to be supported by the reasons presented.

Understanding the structure of an argument is essential in identifying its strengths and weaknesses. By breaking down an argument into its constituent parts, we can evaluate the validity of the reasons presented and determine if the conclusion follows logically. Additionally, conducting thorough research and ensuring that the main conclusion is supported by all the reasons presented is critical in building a strong argument. By employing these techniques, we can strive better critical thinkers and more effective communicators.

To conclude, I hope this blog has provided you with a better understanding of how to analyze and evaluate arguments. The examples used in this blog are taken from a book by Cambridge University, and I highly recommend it to those who want to delve deeper into the topic. Feel free to reach out to me via Instagram or Facebook if you would like the book’s details.

The Mystery Begins

Our vKYC application was acting like a finicky door that wouldn’t stay shut. Users would connect, only to be left buffering, over and over again. It was like watching a digital game of whack-a-mole, and we needed to stop it.

Detective Work: The Network Trail

Our first move? We went full CSI on this one. We captured and analyzed network packets under different scenarios, and that’s when things got interesting. When we bypassed our normal network path, everything worked smoothly - UDP and STUN packets were flowing like a well-orchestrated symphony. But throw our F5 load balancer into the mix? Complete silence. No UDP packets, no STUN packets, nothing.

The Plot Thickens

Armed with these findings, we began our systematic investigation. Think of it as following breadcrumbs through a digital forest. Our trail led us through:

1. The F5 load balancer (our first suspect)
2. The Palo Alto firewall (which was looking more suspicious by the minute)
3. Various network paths that could be causing this digital traffic jam

The Breakthrough Moment

After diving deep into the Palo Alto firewall logs (yes, as exciting as it sounds), we struck gold. The packets weren’t even making it to our F5 load balancer - they were getting lost somewhere in the firewall maze.

Crafting the Solution

Here’s where things get interesting. We took a multi-step approach:

First, we basically created a clone of our existing bypass network policy in the Palo Alto firewall. Think of it as creating a new path through our digital maze, but this time with careful consideration of where it needed to go.

Then came the clever part - we integrated our F5 WAF security zone into the policy framework. It’s like adding a new security checkpoint, but one that actually keeps traffic flowing smoothly.

The Final Twist

The real breakthrough? It came down to the SIP protocol. Initially, we enabled the SIP protocol with the Application Layer Gateway (ALG) disabled, which acted like removing a roadblock. Later, we found we could disable the SIP protocol entirely - and surprisingly, everything worked even better!

Happy Ending

The result? Our vKYC application now runs as smooth as butter. No more constant reconnections, no more frustrated users, just a seamless experience like it should have been from the start.

Key Takeaways

What did we learn from this adventure? Sometimes, the solution to a complex problem lies in systematic investigation and being willing to question every component in your stack. In our case, what seemed like a simple connectivity issue led us through load balancers, firewalls, and protocol configurations before we found our answer.

Remember: in the world of technical troubleshooting, every clue counts, and sometimes the solution might be hiding in the most unexpected place.

Threat classification has been a go to process for categorizing security risks or potential dangers based on their level of severity and impact. This helps organizations prioritize their security measures and allocate resources effectively to mitigate the most critical threats.

Threat Classification Concepts

Known-Knowns

“Known-knowns” refers to the threats that are known and understood by the organization. These threats are well documented, and mitigation strategies are in place.

Known-Unknowns

“Known-unknowns” refers to the threats that are recognized but not fully understood by the organization. While the organization is aware of the potential risks, the exact nature of the threat and its impact remain unclear.

Unknown-Knowns

“Unknown-knowns” refers to situations where an organization is aware of a potential threat but chooses to ignore or dismiss it. This could be due to reasons such as complacency, lack of resources, or the belief that the threat is unlikely to occur.

Unknown-Unknowns

“Unknown-unknowns” refers to threats that are completely unknown to the organization and may emerge from new or unforeseen sources. These threats can be particularly dangerous as the organization is not prepared to mitigate or defend against them.

Conclusion

Threat classification is a vital process for organizations to effectively manage their security risks. By categorizing potential threats based on their level of severity and impact, organizations can prioritize their security measures and allocate resources to mitigate the most critical risks.

It is important for organizations to recognize all types of threats, including known-knowns, known-unknowns, unknown-knowns, and unknown-unknowns. By doing so, they can take proactive measures to reduce the likelihood and impact of security incidents, ensuring the safety and protection of their assets and stakeholders.

The Life of a Packet: A Seven-Step Journey

Think of packet processing in F5 as a security checkpoint at an airport. Every packet goes through a specific order of processing, and understanding this flow is crucial for effective troubleshooting:

1. First Stop: Connection Table Check
   Like a frequent flyer getting fast-tracked, existing connections in the connection table get processed first. It’s your system’s way of saying, “Hey, I know this one!”

2. The Security Check: Packet Filter Rules
   Just as airport security screens passengers, packet filter rules examine incoming traffic. These rules determine whether to allow or block the traffic based on predetermined criteria.

3. Virtual Server Verification
   This is where your packet finds its destination gate. The system checks which virtual server should handle this incoming connection.

4. SNAT Investigation
   Think of SNAT as the customs checkpoint, verifying if the incoming traffic matches with the SNAT pool of IP addresses.

5. NAT Processing
   Like a currency exchange booth between two different zones, NAT checks if translation is needed between different VLANs.

6. Self-IP Verification
   The final identity check - does this packet match any self-IP addresses?

7. The Drop Zone
   If all else fails, like an unclaimed bag at the airport, the packet gets dropped.

Your Troubleshooting Toolkit

When things go wrong (and they will), here’s your arsenal of diagnostic tools:

• Virtual Server stats: Your first line of investigation
• Pool/Pool member stats: For detailed performance metrics
• Logs: Your system’s black box recorder
• Connection table: To track active connections
• Routing table: For complex platform navigation
• Connectivity tests: Ping, telnet, and curl to verify pool member health
• Packet captures: When you need to see the raw truth

Advanced Concepts You Can’t Ignore

Priority Group Activation: The Art of Balance

Imagine having six servers running two applications. Three servers primarily handle one application, while the other three handle another. PGA helps manage this delicate balance, ensuring optimal resource utilization.

Persistence and Fallback: A Different Perspective

Here’s something that might surprise you: when enabled, fallback persistence works concurrently rather than sequentially. It creates a key-value pair system (think cookie → source_IP) that operates simultaneously, not as a backup plan.

Connection Mirroring: Your Safety Net

Think of connection mirroring as your digital backup singer - always ready to take over when needed. It ensures seamless failover by maintaining a mirror of your connections.

Critical Administrative Tips

Archive Management

Remember this golden rule: restoring an archive can cause downtime. Also, your private keys are in there, so treat your archives like crown jewels.

Persistence Profile Configuration

Want to ensure each unique IP address creates a persistence record? Set your netmask to 255.255.255.255. It’s like giving each visitor their own VIP pass.

UCS Restoration via CLI

Need to restore a UCS configuration through the command line? Here’s your magic spell:

load/sys ucs <filepath> passphrase <password>

The Bottom Line

F5 TMOS administration isn’t just about knowing the commands - it’s about understanding the flow, the relationships between components, and knowing where to look when things go sideways. Keep these concepts handy, and you’ll be well-equipped to handle whatever challenges come your way.

Remember: in F5 administration, like in chess, thinking several moves ahead and understanding the relationships between different pieces is key to success.