XEIZE
/Vulnerability documentation/Swift/Hostname validation disabled in an AFNetworking policy without pinning

Hostname validation disabled in an AFNetworking policy without pinning

Hostname validation disabled in an AFNetworking policy without pinning

Description

In AFNetworking 4.0.1, AFSecurityPolicy.default() and pinning mode .none do not pin certificates or public keys, but they validate both the system trust chain and the requested hostname by default. The absence of pinning alone does not make a configuration vulnerable.

Setting validatesDomainName to false in this policy makes AFNetworking evaluate the server certificate using a basic X.509 policy rather than an SSL policy bound to the requested domain. With no pinned certificate or public key either, it can accept a certificate with a valid trust chain that was issued for a different hostname. An attacker who controls the network path can use this to impersonate the server.

AFNetworking 4.0.1 rejects a no-pinning policy with allowInvalidCertificates = true when a domain is provided and hostname validation is enabled. Disabling hostname validation to bypass that rejection can allow arbitrary certificates. Correctly provisioned pins for a specific peer's certificate or public key can provide service identity.

AFNetworking was deprecated on January 17, 2023 and no longer provides new releases. Migrate to a maintained networking library or platform API.

Potential impact

  • A man-in-the-middle attack using a certificate issued by a trusted certificate authority for a different hostname.
  • Reading or modifying server responses and request data.
  • Theft of sensitive information in transit, including session cookies, authentication tokens, and personal information.

Remediation

  1. Keep validatesDomainName set to true in default() and .none policies so that both the system trust chain and the requested hostname are validated.
  2. Do not combine allowInvalidCertificates = true with disabled hostname validation in a no-pinning policy to connect to a self-signed server. Use a publicly trusted certificate or securely provision the certificate or public key for the exact peer before connecting.
  3. Use .certificate or .publicKey only when your threat model requires pinning. Limit the hosts to which pins apply and plan key rotation, backup pins, and connection blocking on failure. Pinning is not mandatory when standard system trust and hostname validation meet your requirements.
  4. Migrate from AFNetworking to the default server trust handling in URLSession or a maintained library such as Alamofire. The Alamofire stable release checked on August 30, 2026 was 5.12.0. With a custom DefaultTrustEvaluator, keep validateHost: true unless peer-specific pinning explicitly supplies the service identity instead.
  5. Test the release configuration to ensure it rejects hostname mismatches, expired certificates, and certificates from untrusted issuers.

Examples

Before

swift
import AFNetworking

func insecurePolicy() -> AFNetworking.AFSecurityPolicy {
    let policy = AFNetworking.AFSecurityPolicy.default()
    policy.validatesDomainName = false
    return policy
}

After

swift
import AFNetworking

func standardPolicy() -> AFNetworking.AFSecurityPolicy {
    let policy = AFNetworking.AFSecurityPolicy.default()
    policy.validatesDomainName = true
    return policy
}

Explanation:

  • Before: The policy checks the trust chain but does not compare the certificate's hostname with the requested destination.
  • After: Both system trust chain validation and hostname validation remain enabled. The default value of validatesDomainName is also true; this assignment makes the security requirement explicit.

When moving to the platform's default server trust handling, do not add unnecessary authentication challenge overrides.

swift
import Foundation

func standardSession() -> URLSession {
    URLSession(configuration: .default)
}

References

XEIZE DocumentationTechnical support