Semgrep swift rules¶
rules_lgpl_swift_other_rule-ios-biometric-acl¶
Summary:
Authentication bypass by primary weakness
Severity: Critical
CWE: CWE-305
Description:
The application uses weak biometric ACL flags like .biometryAny,
.userPresence, or .touchIDAny when calling
SecAccessControlCreateWithFlags() to protect keychain items. These flags
allow any registered biometric on the device to authenticate, meaning an
attacker with physical device access can add their own fingerprint or face
and authenticate as the legitimate user, bypassing the intended security
controls.
Remediation:
Consider using SecAccessControlCreateWithFlags() with the
.biometryCurrentSet flag instead of .biometryAny to ensure only the
currently enrolled biometrics can authenticate. This prevents an attacker
who gains physical device access from adding their own biometrics to
authenticate as the legitimate user. Similarly, prefer .touchIDCurrentSet
over .touchIDAny when working with Touch ID specifically. When creating
access control objects, combine these flags with appropriate keychain
accessibility attributes like kSecAttrAccessibleWhenUnlockedThisDeviceOnly
for defense-in-depth protection. Recommended to also implement additional
authentication factors for high-security operations beyond biometrics alone.
OWASP:
- A2:2017-Broken Authentication
- A07:2021-Identification and Authentication Failures
rules_lgpl_swift_other_rule-ios-file-no-special¶
Summary:
Cleartext storage of sensitive information
Severity: Critical
CWE: CWE-312
Description:
The application uses .noFileProtection or FileProtectionType.none when
writing files, which disables iOS data protection encryption for those files.
Files created with these options are stored unencrypted on disk and remain
accessible even when the device is locked, making them vulnerable to
unauthorized access if the device is physically compromised, during forensic
extraction, or through file system vulnerabilities. This violates iOS security
best practices for protecting sensitive user data at rest.
Remediation:
Consider using FileProtectionType.complete when writing files via
Data.write(to:options:) to ensure files are encrypted and only accessible
when the device is unlocked. For files that need to be accessed during
background tasks while the device is locked, use
FileProtectionType.completeUnlessOpen which protects files except when
already open. For files that must be accessible after first unlock but don't
need the highest protection, use FileProtectionType.completeUntilFirstUserAuthentication.
Recommended to use FileProtectionType.complete as the default for sensitive
data like user credentials, personal information, or financial data. Note
that Core Data and keychain APIs have separate protection mechanisms and
should be used for highly sensitive data rather than file-based storage.
OWASP:
- A3:2017-Sensitive Data Exposure
- A02:2021-Cryptographic Failures
rules_lgpl_swift_other_rule-ios-tls3-not-used¶
Summary:
Selection of less-secure algorithm during negotiation ('algorithm downgrade')
Severity: Critical
CWE: CWE-757
Description:
The application sets TLSMinimumSupportedProtocolVersion to .TLSv1_0,
.TLSv1_1, or .TLSv1_2, which are outdated TLS protocol versions. TLS
1.0 and 1.1 were officially deprecated by the IETF in March 2021 due to
known vulnerabilities including susceptibility to BEAST, POODLE, and other
downgrade attacks. While TLS 1.2 is still widely supported, it lacks the
modern security improvements of TLS 1.3 including forward secrecy by
default, simplified handshake reducing attack surface, and removal of legacy
cryptographic algorithms. Using older TLS versions exposes the application
to man-in-the-middle attacks and protocol-level vulnerabilities.
Remediation:
Consider upgrading to TLS 1.3 by setting TLSMinimumSupportedProtocolVersion
to .TLSv13 in URLSessionConfiguration or when configuring NWParameters
for network connections. TLS 1.3 provides significant security improvements
including mandatory perfect forward secrecy, encrypted handshake metadata,
and removal of vulnerable cipher suites. When using URLSession, configure
the session with .default or .ephemeral configuration and explicitly set
the minimum protocol version. Recommended to test thoroughly as some legacy
servers may not support TLS 1.3, in which case TLS 1.2 can be used as a
fallback with enforced strong cipher suites. Consider implementing certificate
pinning alongside TLS 1.3 for additional protection against certificate
authority compromises.
OWASP:
- A6:2017-Security Misconfiguration
- A05:2021-Security Misconfiguration
rules_lgpl_swift_other_rule-ios-dtls1-used¶
Summary:
Selection of less-secure algorithm during negotiation ('algorithm downgrade')
Severity: Medium
CWE: CWE-757
Description:
The application configures TLSMinimumSupportedProtocolVersion to use
DTLSv10 (DTLS 1.0), which is an outdated and insecure protocol version.
DTLS 1.0 inherits vulnerabilities from TLS 1.0 including susceptibility to
BEAST attacks, weak cipher suites, and lack of modern cryptographic
protections. DTLS is used for securing datagram-based protocols like UDP,
and using version 1.0 exposes the application to known security weaknesses
that can compromise the confidentiality and integrity of transmitted data.
Remediation:
Consider upgrading to DTLS 1.2 by setting
TLSMinimumSupportedProtocolVersion to .DTLSv12 when configuring network
connections using the Network framework or similar APIs. DTLS 1.2 provides
stronger cipher suites, improved handshake security, and protections against
known attacks on earlier versions. When using NWParameters for UDP
connections, configure the security options to explicitly require DTLS 1.2 or
higher. Recommended to also review and enforce strong cipher suite selection
to prevent downgrade attacks. Note that DTLS 1.3 support may be available in
newer iOS versions and should be preferred when backward compatibility with
older systems is not required.
OWASP:
- A6:2017-Security Misconfiguration
- A05:2021-Security Misconfiguration
rules_lgpl_swift_other_rule-ios-keychain-weak-accessibility-value¶
Summary:
Authentication bypass by primary weakness
Severity: Medium
CWE: CWE-305
Description:
The application uses weak keychain accessibility attributes
kSecAttrAccessibleAlways or kSecAttrAccessibleAfterFirstUnlock when
storing items via SecItemAdd() or related keychain APIs.
kSecAttrAccessibleAlways allows keychain items to be accessed even when
the device is locked, providing no protection against physical device
compromise. kSecAttrAccessibleAfterFirstUnlock makes items accessible
after the first unlock following a reboot, meaning they remain accessible
for the entire uptime of the device regardless of lock state. Both options
fail to leverage iOS data protection to secure sensitive data when the
device is locked.
Remediation:
Consider using kSecAttrAccessibleWhenUnlocked as the value for
kSecAttrAccessible in keychain queries to ensure items are only
accessible when the device is unlocked. For items that should not sync
across devices, use kSecAttrAccessibleWhenUnlockedThisDeviceOnly which
provides both encryption when locked and prevents iCloud Keychain
synchronization. For extremely sensitive data like authentication tokens or
encryption keys, consider combining keychain storage with additional
biometric or passcode authentication using SecAccessControl with
.userPresence or .biometryCurrentSet flags. Recommended to audit all
keychain items and migrate legacy kSecAttrAccessibleAlways usage to
stronger protection classes appropriate for each data type's sensitivity
level.
OWASP:
- A2:2017-Broken Authentication
- A07:2021-Identification and Authentication Failures