# F5XC object linter

> Paste an F5XC origin_pool, http_loadbalancer, or app_firewall object and it flags risky or surprising settings, each with a severity and a grounded explanation.

- Tool: https://ronutz.com/en/tools/f5xc-object-linter
- Family: Security & WAF

---

## What it does

This tool is a linter for F5 Distributed Cloud (XC) configuration objects. Paste an origin_pool, http_loadbalancer, or app_firewall object - from the Console's JSON view or the API - and it flags settings that are risky, surprising, or likely mistakes, each with a severity and a short explanation grounded in F5's documentation. It runs entirely in your browser, and it introduces no new schema: every rule reuses the object structures verified for the other tools in this family.

## What it checks

For an origin pool, the linter flags TLS to the origin with server verification skipped (the connection is encrypted but the origin's certificate is not validated), SNI disabled, cleartext to the origin, an absent health check, and a single origin server with no redundancy. For an HTTP load balancer, it flags no WAF attached, a plain-HTTP listener with no HTTPS, HTTPS configured without an HTTP-to-HTTPS redirect, a route that disables the WAF, a catch-all route placed before other routes (which can never match under first-match evaluation), and a wildcard domain mixed with its apex. For a WAF, it flags monitoring mode (detects but does not block) and disabled threat campaigns.

## Severity and grounding

Each finding carries a severity - high, warn, or info - and the list is sorted with the most serious first. High is reserved for a setting that materially weakens security, like skipping origin verification. Warn covers settings that are usually wrong, like no WAF or a shadowed route. Info covers things worth knowing but often intentional, like a single origin. Every rule cites the F5 source it is based on, so a flag is a starting point for a decision rather than a verdict - some of these settings are the right choice in context, and the linter says why each one matters so you can decide.

## What it is not

The linter reads one object at a time and reasons only about what is inside it. It cannot see whether a WAF referenced by name is itself in monitoring mode, or whether an origin pool referenced by a route carries a weight - those live in other objects. It is a fast first pass over a single object's own settings, not a full configuration audit.

## Standards and references

- [F5 Distributed Cloud: Create Origin Pools (TLS-to-origin, Skip Verification, SNI, health checks)](https://docs.cloud.f5.com/docs-v2/multi-cloud-app-connect/how-to/app-networking/origin-pools) - grounds the origin-pool rules: skip-verification risk, no_tls cleartext, disabled SNI, absent health checks
- [F5 Distributed Cloud: Create HTTP Load Balancer (WAF attachment, HTTP->HTTPS redirect, routes)](https://docs.cloud.f5.com/docs-v2/multi-cloud-app-connect/how-to/load-balance/create-http-load-balancer) - grounds the LB rules: WAF is opt-in, http_redirect, plain-HTTP listener, and per-route WAF disable
- [DevCentral: F5 Distributed Cloud - Listener Logic + first-match routing (route shadowing, wildcard vs apex)](https://community.f5.com/kb/technicalarticles/f5-distributed-cloud---listener-logic/326096) - grounds the catch-all route-shadowing rule (first-match) and the wildcard+apex caution
- [F5 Distributed Cloud: Create Web Application Firewall (Blocking vs Monitoring enforcement, threat campaigns)](https://docs.cloud.f5.com/docs-v2/web-app-and-api-protection/how-to/app-security/application-firewall) - grounds the WAF rule: monitoring mode detects but does not block; disabled threat campaigns

## Related reading

- [Common XC Config Hazards a Linter Can Catch](https://ronutz.com/en/learn/f5xc-config-hazards.md): XC objects accept settings that are valid but operationally wrong. This walks the hazards a single-object linter can flag: origin-pool skip-verification, cleartext, disabled SNI, and missing health checks; load-balancer no-WAF, plain-HTTP listeners, missing HTTP-to-HTTPS redirect, per-route WAF disable, catch-all route shadowing, and wildcard+apex; and a WAF left in monitoring mode - plus why severity is a prioritizer, not a verdict, and the limits of reading one object at a time.