Swift Static Analysis: iOS App Security, Keychain, and the Mobile Attack Surface

In July 2024, EVA Information Security disclosed a set of supply-chain vulnerabilities affecting the CocoaPods dependency manager that had quietly persisted for nearly a decade. The most severe finding let an attacker claim ownership of any pod whose original maintainer had been removed during a 2014 trunk-server migration, which left thousands of pods orphaned with no email address bound to them. A single unauthenticated API call could re-attach a pod to an attacker-controlled account, after which the next release would propagate to every iOS application that listed that pod in its Podfile. CocoaPods is consumed by roughly three million iOS apps and is woven through Apple's own first-party tooling. The advisory did not surface a confirmed in-the-wild compromise, but it framed the threat model every Swift team has to take seriously: the iOS attack surface is not just the code your engineers write, it is also the keychain entitlements they request, the App Transport Security exceptions they ship, the deep link handlers they expose, and the dependencies they pull in without reading.

Swift sits in an unusual position among production languages. Memory safety, value semantics, and option-typed nullability close several entire vulnerability classes at the type-system level, and ARC removes the manual lifecycle bookkeeping that drove a generation of Objective-C use-after-frees. The bugs that survive are the ones Apple's compiler cannot reason about: where a credential lands on disk, which entitlement protects it, what the WebView is willing to execute, and whether a deep link parameter ever reaches a sink that trusts it. This guide walks through the iOS vulnerability landscape swift static analysis is built to surface and explains where a swift security scanner earns its place. The patterns below are the floor — any serious swift sast engine should catch them on the diff that introduces them.

The Swift and iOS Vulnerability Landscape

The OWASP Mobile Application Security Verification Standard organizes the iOS attack surface into eight control families, and four dominate real-world findings. Insecure data storage is the most common: developers reach for UserDefaults as a key-value store, drop authentication tokens or PII into it, and ship an app whose plist file lands in an unencrypted backup the moment the device syncs to iCloud. The same pattern shows up with raw FileManager writes to the Documents directory, with SQLite databases created without SQLCipher, and with Core Data stores configured with no file protection class. MASVS-STORAGE collapses these into a single rule: sensitive data belongs in the Keychain with the strictest accessibility class the use case allows.

Insecure communication is the second cluster. App Transport Security has been on by default since iOS 9, but the NSAppTransportSecurity dictionary in Info.plist still ships with NSAllowsArbitraryLoads set to true in apps whose engineers found cleartext easier than wiring TLS into a development backend. Certificate pinning is absent from most apps that claim to handle financial or health data. Keychain misuse — storing a credential with kSecAttrAccessibleAlways when kSecAttrAccessibleWhenUnlockedThisDeviceOnly was the right answer — exposes data on a locked device that subsequently leaves the user's possession. URL scheme hijacking lets a malicious app register the same custom scheme and receive deep links intended for the legitimate one, which is why Universal Links exist and why CWE-940 catalogues the older shape. WebView vulnerabilities persist because UIWebView shipped without origin isolation for the WebKit JS context; even WKWebView becomes dangerous the moment a developer enables JavaScript on untrusted HTML or installs a script message handler that trusts its payload. Hardcoded API keys in Info.plist and Swift constants round out the catalog.

Insecure Data Storage: UserDefaults Is Not a Vault

The vulnerable shape is short, idiomatic, and ships in tutorials. A login flow receives a token from the backend and persists it where the next view controller can read it back:

// VULNERABLE
import Foundation

func saveAuthToken(_ token: String) {
    UserDefaults.standard.set(token, forKey: "auth_token")
}

func loadAuthToken() -> String? {
    return UserDefaults.standard.string(forKey: "auth_token")
}

UserDefaults writes the value into a property list inside the app sandbox. That file is unencrypted at rest, included in iCloud backups unless the developer explicitly excludes it, and trivially recoverable from a jailbroken device or a forensic image. The fix is to move the token into the Keychain with an accessibility class that ties it to the device and the unlocked state:

// FIXED
import Foundation
import Security

func saveAuthToken(_ token: String) -> OSStatus {
    guard let data = token.data(using: .utf8) else { return errSecParam }
    let query: [String: Any] = [
        kSecClass as String: kSecClassGenericPassword,
        kSecAttrAccount as String: "auth_token",
        kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
        kSecValueData as String: data
    ]
    SecItemDelete(query as CFDictionary)
    return SecItemAdd(query as CFDictionary, nil)
}

kSecAttrAccessibleWhenUnlockedThisDeviceOnly is the correct default for an authentication token: the value is decryptable only when the device is unlocked, and the ThisDeviceOnly suffix excludes the item from backups, so a stolen iCloud archive cannot resurrect the credential on attacker hardware. SAST recognizes the UserDefaults.set sink reached by any value named like a credential — token, password, secret, JWT — and flags the path before the build leaves the developer's branch. See the A02 Cryptographic Failures guide for the broader taxonomy.

App Transport Security: The Info.plist Flag That Disables HTTPS

The vulnerable construction is split across two files. The Info.plist opens cleartext globally, and the Swift code makes a request whose URL the developer typed by hand:

// VULNERABLE — Info.plist
// <key>NSAppTransportSecurity</key>
// <dict>
//   <key>NSAllowsArbitraryLoads</key>
//   <true/>
// </dict>

import Foundation

func fetchProfile(userId: String) {
    let url = URL(string: "http://api.example.com/users/\(userId)")!
    URLSession.shared.dataTask(with: url) { data, _, _ in
        // ...
    }.resume()
}

Cleartext HTTP on a public URL means any network position between the device and the origin — a hostile access point, a carrier middlebox, an ISP that sells session data — can read and modify the response. The fix is to delete the ATS exception, switch the scheme, and let the platform refuse anything weaker:

// FIXED — Info.plist contains no ATS exception
import Foundation

func fetchProfile(userId: String) {
    guard let url = URL(string: "https://api.example.com/users/\(userId)") else { return }
    URLSession.shared.dataTask(with: url) { data, _, _ in
        // ...
    }.resume()
}

With ATS at its defaults, iOS refuses any connection that is not TLS 1.2 or higher, fails closed on a broken cipher suite, and rejects certificates outside the system trust store. For applications handling regulated data, layer certificate pinning on top by implementing urlSession(_:didReceive:completionHandler:) and comparing the server certificate against a pinned hash. SAST flags any NSAllowsArbitraryLoads entry, any NSExceptionDomains dictionary that lowers the bar for a specific host, and any http:// URL constructed inside Swift source.

WKWebView: JavaScript Enabled on Untrusted Content

WKWebView is the modern, process-isolated successor to the deprecated UIWebView, but isolation does not protect against content the host application itself decided to render. The vulnerable shape loads remote HTML, leaves JavaScript enabled, and exposes a script message handler that trusts whatever the page sends:

// VULNERABLE
import WebKit

final class HelpViewController: UIViewController, WKScriptMessageHandler {
    var webView: WKWebView!

    override func viewDidLoad() {
        super.viewDidLoad()
        let config = WKWebViewConfiguration()
        config.preferences.javaScriptEnabled = true
        config.userContentController.add(self, name: "nativeBridge")
        webView = WKWebView(frame: view.bounds, configuration: config)
        view.addSubview(webView)
        let url = URL(string: "https://help.example.com/article?id=\(articleId)")!
        webView.load(URLRequest(url: url))
    }

    func userContentController(_ ucc: WKUserContentController,
                               didReceive message: WKScriptMessage) {
        if let cmd = message.body as? String {
            UIApplication.shared.open(URL(string: cmd)!)
        }
    }
}

Any reflected or stored XSS in the help origin reaches the JS bridge and calls UIApplication.open with an attacker-controlled URL, which can launch deep links into other apps, trigger telephony, or pivot back into the host application's URL scheme handler. The fix is to constrain what the WebView is willing to load and to validate everything the bridge receives:

// FIXED
import WebKit

final class HelpViewController: UIViewController, WKScriptMessageHandler, WKNavigationDelegate {
    var webView: WKWebView!
    private let allowedHost = "help.example.com"

    override func viewDidLoad() {
        super.viewDidLoad()
        let config = WKWebViewConfiguration()
        config.userContentController.add(self, name: "nativeBridge")
        webView = WKWebView(frame: view.bounds, configuration: config)
        webView.navigationDelegate = self
        view.addSubview(webView)
        guard let articleId = UInt(rawArticleId),
              let url = URL(string: "https://\(allowedHost)/article?id=\(articleId)") else { return }
        webView.load(URLRequest(url: url))
    }

    func webView(_ webView: WKWebView,
                 decidePolicyFor navigationAction: WKNavigationAction,
                 decisionHandler: @escaping (WKNavigationActionPolicy) -> Void) {
        if navigationAction.request.url?.host == allowedHost {
            decisionHandler(.allow)
        } else {
            decisionHandler(.cancel)
        }
    }

    func userContentController(_ ucc: WKUserContentController,
                               didReceive message: WKScriptMessage) {
        guard let dict = message.body as? [String: String],
              dict["action"] == "openSupportTicket" else { return }
        // Route through a typed, validated handler — never UIApplication.open with raw input.
    }
}

The article id is parsed as an unsigned integer before it lands in the URL, the navigation delegate refuses any host outside the allowed origin, and the bridge handler accepts only a structured payload with an enumerated action. SAST traces tainted query parameters into WKWebView.load and flags any handler that opens a URL constructed from WKScriptMessage.body without validation.

Detection: Where Swift SAST Earns Its Keep

Swift gives static analyzers a rich substrate. Strong typing, value semantics, optionals, and access-control modifiers narrow the set of legal data flows, and the compiler's type-checker resolves most call targets without dynamic dispatch ambiguity. The open-source baseline is SwiftLint, which catches style issues and a handful of security-relevant configurations but does not perform inter-procedural taint flow. Apple's scan-build wraps the Clang static analyzer for Swift and Objective-C and remains useful for memory and lifecycle issues anywhere a Swift file still bridges into Objective-C or C. Commercial Swift SAST engines — GraphNode, Checkmarx, Fortify, Veracode — add the inter-procedural data flow, the platform-API rule packs, and the Info.plist configuration analysis that close the gap. Mobile teams pair the SAST engine with the OWASP Mobile Application Security Testing Guide (MASTG) for runtime verification and with MASVS as the requirements baseline. The cheapest moment to fix an iOS vulnerability is the keystroke that introduced it.

Prevention Checklist for Swift and iOS Codebases

Six rules close the overwhelming majority of real-world iOS vulnerabilities. They assume the team has already wired SAST into the pull-request gate; without that, even the strongest checklist degrades to a wiki page nobody re-reads.

• Move every credential into the Keychain. Forbid UserDefaults, raw FileManager writes, and unencrypted SQLite for tokens, passwords, PII, and session state. Pick the strictest accessibility class the use case allows — kSecAttrAccessibleWhenUnlockedThisDeviceOnly is the safe default.
• Keep App Transport Security at its defaults. Delete every NSAllowsArbitraryLoads and NSExceptionDomains entry from Info.plist; if a backend cannot speak TLS 1.2, fix the backend rather than the client. Add certificate pinning on top for any application handling regulated data.
• Harden every WebView at construction. Disable JavaScript on untrusted content, install a WKNavigationDelegate that allowlists hosts, and treat WKScriptMessage.body as untrusted input that must be parsed into a typed payload before it reaches a sink.
• Replace custom URL schemes with Universal Links. Custom schemes are claimed first-come-first-served and let any installed app intercept your deep links. Universal Links bind to a verified domain through the apple-app-site-association file and survive the threat model that CWE-940 catalogues.
• Validate every deep link parameter at the entry point. Treat values from application(_:open:options:) and UIScene link handlers as taint sources. Parse them into typed values, reject anything outside the expected shape, and never feed them into navigation, network, or JavaScript-bridge sinks unsanitized.
• Move secrets out of the bundle. Replace API keys hardcoded in Info.plist, Swift constants, and obfuscated strings with values fetched from the backend after authentication, or with App Attest and DeviceCheck where the threat model fits. Pair the migration with a SAST and secret-scanning gate that fails the build on regression.

Where GraphNode SAST Fits

GraphNode SAST ships native Swift support alongside twelve other languages, with data flow tracking on the patterns this guide describes — credentials reaching UserDefaults, ATS exceptions in Info.plist, WebView configurations that enable JavaScript on untrusted origins, deep link parameters reaching navigation sinks, and hardcoded secrets in bundle resources. The Xcode integration surfaces findings on the keystroke that introduced them; CI gates the pull request before the IPA is signed. For a landscape view, the SAST Tools Buyer's Guide compares ten platforms.

Closing

Swift's type system closes several vulnerability classes that dominated Objective-C, but the iOS attack surface is not a memory-safety problem. It is a question of where credentials land, what the network stack will accept, what the WebView is willing to execute, and which deep links a malicious app can intercept. Static analysis works on Swift because the language gives it the call graph and the type information that make taint flow tractable. The teams that stop shipping mobile-specific breaches are the ones that move detection upstream into the diff and treat the SAST finding as a blocker rather than a backlog ticket.