F5 ASM OWASP & DataGuard — Stop the Leak on the Way Out

① OWASP coverage — what the policy actually maps to

The OWASP Top 10 is the auditor's checklist of the most critical web-app risks. A WAF's job is to address as many as it can — and to prove it. BIG-IP Advanced WAF (formerly ASM) maps the controls in your policy to each OWASP category, so you can show coverage instead of claiming it.

Different policy controls cover different OWASP risks. Attack signatures and meta-character/parameter checks address Injection (A03) and parts of insecure design. Positive security (allow-listed URLs and parameters) constrains the attack surface. Evasion-technique handling stops attackers smuggling injections past signatures with odd encoding. And the response side — DataGuard plus response cloaking — addresses information leakage / sensitive-data exposure, the part most WAFs forget. ASM gives you an OWASP Compliance view that lists each Top 10 category and shows which policy controls cover it.

② Request vs response — two directions, two jobs

This is the mental model that makes everything click: a WAF policy works in two directions, and most engineers only think about one.

The request side is the door coming in. Attack signatures, positive security, parameter and meta-character checks, and evasion normalization all inspect what the client sends — they stop the attack getting through. This is the half everyone configures.

The response side is the exit going out. DataGuard inspects what the server returns — it masks sensitive data and (with response cloaking) hides verbose errors and server headers. This is the half that prevents the breach you'd actually have to report.

Analogy: airport security checks people and bags coming in (request side). But customs also checks what leaves the country — you can't walk out with someone else's passport (response side). A WAF that only checks the entrance lets your data walk out the exit.

③ DataGuard masking — cards, SSNs, and your own patterns

DataGuard is response-side data masking. When the server returns content, DataGuard scans it for sensitive data and masks the matched characters (e.g. 4111********1111) so the browser — and any attacker — never sees the full value.

It covers three kinds of pattern:

• Credit-card numbers — a built-in option. Turn it on and DataGuard masks card-number patterns in responses.
• U.S. SSN — another built-in option for the classic 3-2-4 social-security format.
• Custom patterns — your own regex for formats DataGuard doesn't know: an internal employee ID (ECN-7-digits), an account number, an Aadhaar-style ID. Add the pattern and DataGuard masks it too.

You can also scope DataGuard to specific URLs (e.g. only the account pages), and pair it with response cloaking to hide verbose errors and server headers that help an attacker fingerprint the app.

Analogy: DataGuard is the bank teller who blacks out all but the last 4 digits on a printed statement. The full number exists in the system, but what leaves the counter is masked — even if someone grabs the paper.

Build it — the configuration

Map the policy's OWASP controls on the request side, then enable DataGuard on the response side with the built-ins plus your custom pattern.

Security ▸ Application Security ▸ Data Guard  (policy: app_pol)
  Data Guard:               Enabled
  Credit Card Numbers:      Mask
  U.S. Social Security:     Mask
  Custom Patterns:          ECN-[0-9]{7}        # internal employee ID format
  Enforced URLs:            * (or scope to /account/*, /statement/*)
  Response Cloaking:        Enabled  (suppress server headers + verbose errors)
Apply Policy

Policy "app_pol" applied. Data Guard active (response side).
  mask: credit-card ON · us-ssn ON · custom [ECN-[0-9]{7}] ON
  response-cloaking ON
# Reminder: masking only APPLIES when the policy is in Blocking (enforced) mode, not Transparent.

tmsh list asm policy app_pol data-guard
tmsh list asm policy app_pol enforcement-mode

data-guard {
    enabled yes
    mask-credit-card-numbers yes
    mask-us-social-security-numbers yes
    custom-patterns { ECN-[0-9]{7} }
}
enforcement-mode blocking
# enforcement-mode transparent here = detects but does NOT mask. Switch to blocking.

The four response-side mechanics — tap each card

Each card front names the mechanic; the back gives you the "so what" — when to reach for it.

④ Tune & validate — exceptions, cloaking, and the proof

DataGuard's flexibility is also its noise source: a pattern that matches cards will also match anything shaped like a card. Two tuning levers fix that without weakening real protection.

• Exceptions / scoping — when a safe look-alike (a 16-digit order ID, an invoice number) gets masked and breaks a page, add an exception for that value, or scope DataGuard to the URLs that actually carry sensitive data. You keep masking ON; you just stop it firing on the wrong thing.
• Response cloaking — turn on cloaking so verbose error pages, stack traces and server/version headers are suppressed. These don't leak customer data, but they leak your data — the app's internals — and help an attacker target you.

And then the rule that ends every argument: validate. Never claim DataGuard works from the config screen. Request a page that genuinely contains a test card (in a lab), and look at the delivered response — is the value masked? Then open the event log and confirm a DataGuard/data-leakage violation was recorded. If the response shows the full card, the most common cause is that the policy is in Transparent mode (logs but doesn't enforce) — masking only applies in Blocking mode.

curl -ks https://10.10.20.5/account/statement -H "Cookie: $SESSION" | grep -i card
# look at what the CLIENT actually receives, not the config screen

<div class="pan">Card on file: 4111********1111</div>
# Masked → DataGuard is enforcing.
# If you see 4111111111111111 → policy is Transparent, or DataGuard isn't scoped to this URL/content-type.