ATS Exception and a WebView That Leaks a Session Cookie
A retail iOS app (version 3.1, iOS 17 test device) uses ATS with NSAllowsArbitraryLoads=false. Its Info.plist has an NSExceptionDomains entry for cdn.example-retail.com with NSExceptionAllowsInsecureHTTPLoads=true and NSIncludesSubdomains=true, and a second entry for help.example-retail.com with the same flags. The app loads a help page in WKWebView from http://help.example-retail.com/start, which returns a 301 redirect to HTTPS. The session cookie sid is set by the API with domain .example-retail.com, Secure=false, HttpOnly=true, and a 30-day lifetime. Through an intercepting proxy, the tester sees the initial HTTP GET to help.example-retail.com include the sid cookie before the redirect. The API itself is HTTPS-only and uses a valid certificate. The team says the redirect makes the HTTP request harmless and wants to ship.
1. Is the HTTP request harmless because it redirects to HTTPS? Explain the exposure and the role of the cookie attributes.
Read the worked answer
No. The 301 is a response to a request that has already been sent in cleartext. The sid cookie is scoped to .example-retail.com, so it matches help.example-retail.com; because Secure is false, the client will send it over HTTP. HttpOnly only blocks JavaScript access, not network capture. An attacker on the same Wi-Fi can read the 30-day sid from the initial GET and replay it to the HTTPS API. The redirect protects subsequent requests, not the first one. HSTS would help only after a successful HTTPS response with the header, and not for the first request, so it is not a fix here.
2. Evaluate the ATS exception scope and propose a corrected configuration and code-level controls.
Read the worked answer
The ATS exception is broader than necessary: NSIncludesSubdomains=true applies the insecure-load allowance to every subdomain of example-retail.com, not just help. Remove NSExceptionAllowsInsecureHTTPLoads. If a legacy host truly needs HTTP, scope it to the exact host, set NSExceptionMinimumTLSVersion to TLS 1.2 or higher, and never allow cookies on it. Set Secure and a narrow cookie domain, or use a __Host- prefix with no Domain and path /, on sid. Use WKAppBoundDomains to restrict the web view to intended HTTPS hosts, and block cleartext at the app layer. Load help over HTTPS only.
3. How would you verify the remediation?
Read the worked answer
Rerun the proxy with a user CA and confirm that HTTP to help fails. Inspect the built Info.plist for any NSExceptionAllowsInsecureHTTPLoads or NSAllowsArbitraryLoads. Inspect Set-Cookie for Secure, HttpOnly, SameSite, and domain scope. Use a test account and confirm that no sid appears on any HTTP request. Start from an HTTPS page and test redirects. Confirm that WKWebView cannot load an HTTP URL and that WKAppBoundDomains is enforced. Also verify behavior on a cold install, because cached HSTS or cookies can hide the first-request leak.