Domain fronting works by presenting a benign or allowed hostname in the TLS ClientHello SNI field while the actual intended destination is embedded in the encrypted HTTP Host header, exploiting the fact that many security controls historically made policy decisions based on the SNI alone, before decryption exposed the true host being requested. The correct defense operates at the SSL Decryption layer itself: when Prisma Access decrypts the session, it can compare the SNI presented during the handshake against the Subject Alternative Name/Common Name actually returned in the server ' s certificate, and the " Block sessions on SNI mismatch with Server Certificate (SAN/CN) " decryption profile setting will terminate any session where these values do not agree — which is exactly the signature of a domain-fronting attempt, since the fake SNI will not match the certificate genuinely presented by the real destination server. This makes option D the correct, purpose-built control. There is no " Domain Fronting " toggle within Advanced Threat Prevention (option A); ATP focuses on exploit and vulnerability signatures, not SNI/certificate correlation. Advanced URL Filtering ' s " Malicious Behavior " category (option B) is a URL reputation classification and does not perform SNI-versus-certificate comparison. Option C names a setting that does not exist as an Advanced URL Filtering control; SNI-mismatch detection and enforcement is a decryption-profile capability, not a URL filtering category action, which is the key distinction separating the correct answer from this distractor.