Capability Map
The web security layer decomposes into eight capabilities across five layers of trust. This is the architecture; each row becomes its own deep-dive.
Mental model: establish trust (who + what device) → maintain it (every request) → protect the environment (the browser) → enforce it (the gateway) → judge it (risk + fraud).
| # | Capability | The need | Ways to achieve it | Standard |
|---|---|---|---|---|
| C1 | User Authentication | Prove the person is the genuine customer, un-replayably. | WebAuthn/FIDO2 passkeys; OIDC + PKCE; OTP fallback (weak). | FIDO2, OIDC |
| C2 | Device Binding & Request Integrity | Tie the session to a device and prove every call — the web equivalent of the mobile enclave key + per-request hash. | Device-bound passkey / WebCrypto key; DPoP or mTLS; short-lived tokens; PSD2 dynamic linking. | FAPI 2.0, WebAuthn, DPoP |
| C3 | Browser / Client-Side Security | Lock down delivery, rendering and client code (clickjacking, Magecart, XSS). | TLS/HSTS, CSP, frame-ancestors, SameSite cookies, CORS, anti-CSRF; SRI, RASP, DOM monitoring. | OWASP ASVS, CSP |
| C4 | Anti-Phishing | Prevent and detect credential-harvesting; make harvested credentials useless. | Origin-bound passkeys; DMARC/DKIM/SPF; brand + look-alike domain monitoring. | FIDO, DMARC |
| C5 | Gateway / API Edge | One point that applies the web-channel policy and validates PoP tokens, without changing product APIs. | Channel-aware policy; DPoP/mTLS validation + anti-replay; FAPI 2.0 (PAR, PKCE); WAF; bot management. | FAPI 2.0, OAuth2 |
| C6 | Fraud & Malware / Device-Threat | Detect compromised devices, RATs, emulators, known-fraud devices. | Malware/RAT/emulator SDK; ThreatMetrix; bot detection; connection anomaly. | Vendor (ThreatMetrix) |
| C7 | Device Intelligence & Behavioral | Continuous signal beyond login feeding the risk decision. | Fingerprinting + reputation; behavioral biometrics; velocity/geo. | Vendor integration |
| C8 | Risk Decisioning & Adaptive Step-Up | Decide in real time: allow, challenge, or block — offsetting the web’s structural weakness. | Risk engine (rules + ML); step-up orchestration; PSD2 TRA exemptions; gateway tie-in. | PSD2 SCA/RTS |
Why C1, C2 and C8 are the load-bearing three
C2 is the direct translation of what the mobile bank already runs — bind a key, prove every request. C1 is the front door. C8 is the piece that makes the whole thing hold: because the web has no hardware root of trust, no single checkpoint can be as certain as mobile, so you continuously judge risk and step up when it rises. Without C8, the fraud and device signals (C6/C7) are data with nowhere to go.
Open structural note
C6 and C7 are often the same vendor (ThreatMetrix sells both) and could merge into “Device & Fraud Intelligence.” Kept separate here because malware/RAT detection and behavioral biometrics are genuinely different technical capabilities feeding the same brain (C8).