Segurança de aplicativos Swift: top 10 vulnerabilidades na prática

Segurança de aplicativos Swift: top 10 vulnerabilidades na prática

O desenvolvimento de aplicativos móveis para iOS e macOS exige atenção especial à segurança. Swift é uma linguagem poderosa e moderna, mas nem mesmo ela protege o desenvolvedor de erros típicos que podem levar a vazamento de dados, invasão ou perdas financeiras. Neste artigo, analisaremos as top 10 vulnerabilidades de aplicativos Swift com exemplos reais de código e recomendações práticas para corrigi-las.

1. Injeções SQL via Core Data e SQLite

Muitos desenvolvedores usam consultas SQL brutas em conjunto com SQLite. Se os dados do usuário não forem escapados, um invasor pode executar uma consulta arbitrária no banco de dados.

// ❌ Código vulnerável\nlet query = "SELECT * FROM users WHERE name = '\\(userInput)'"\n\n// ✅ Código seguro (uso de consultas parametrizadas)\nlet query = "SELECT * FROM users WHERE name = ?"\nvar statement: OpaquePointer?\nsqlite3_prepare_v2(database, query, -1, &statement, nil)\nsqlite3_bind_text(statement, 1, (userInput as NSString).utf8String, -1, nil)\n

Use consultas parametrizadas ou Core Data com predicados — isso elimina injeções.

2. Armazenamento inseguro de dados no Keychain

O Keychain é um local seguro, mas muitos desenvolvedores configuram incorretamente os atributos de acesso. Por exemplo, se kSecAttrAccessible não for especificado, os dados podem ficar acessíveis após o backup.

// ❌ Código vulnerável (acessível após backup)\nlet query: [String: Any] = [\n    kSecClass as String: kSecClassGenericPassword,\n    kSecAttrAccount as String: "token",\n    kSecValueData as String: tokenData\n]\n\n// ✅ Código seguro (apenas quando o dispositivo está desbloqueado)\nlet query: [String: Any] = [\n    kSecClass as String: kSecClassGenericPassword,\n    kSecAttrAccount as String: "token",\n    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly,\n    kSecValueData as String: tokenData\n]\n

3. Ausência de verificação SSL/TLS (Man-in-the-Middle)

Durante o desenvolvimento, a verificação de certificados é frequentemente desabilitada para testes, mas as configurações são esquecidas na versão de lançamento. Isso permite que um invasor intercepte o tráfego.

// ❌ Código vulnerável (perigoso para produção)\nlet session = URLSession(configuration: .default, delegate: self, delegateQueue: nil)\n// No delegate:\nfunc urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {\n    completionHandler(.useCredential, URLCredential(trust: challenge.protectionSpace.serverTrust!))\n}\n\n// ✅ Código seguro — use a verificação padrão\nlet session = URLSession.shared\n// Ou use ATS (App Transport Security) no Info.plist\n

Ative o App Transport Security (ATS) e não o desabilite na compilação de lançamento.

4. Vazamento de dados via logs e Crashlytics

Desenvolvedores frequentemente registram dados sensíveis (tokens, senhas) para depuração. Se o log for para um serviço terceiro (ex.: Firebase Crashlytics), os dados vazam.

// ❌ Código vulnerável\nprint("User token: \\(userToken)")\n\n// ✅ Código seguro\n#if DEBUG\n    print("User token: [REDACTED]")\n#endif\n// Ou use os_log com nível de privacidade\nos_log("User token: %{private}@", log: .default, type: .debug, userToken)\n

Nunca registre dados sensíveis em produção. Use mascaramento ou compilação condicional.

5. Armazenamento inseguro de segredos no código

Armazenar chaves de API, tokens e senhas diretamente no código-fonte é um erro grave. Mesmo que o código seja ofuscado, as strings podem ser facilmente extraídas do arquivo binário.

// ❌ Código vulnerável\nlet apiKey = "sk-1234567890abcdef"\n\n// ✅ Código seguro — use autenticação no servidor\n// Ou criptografe as chaves com CryptoKit\nimport CryptoKit\nlet key = SymmetricKey(data: "server_