Home / Attacks & tests / Transport Layer Security (TLS) Vulnerabilities
12 test cases
Transport Layer Security (TLS) Vulnerabilities
Transport testing examines every channel the application opens, not only the one the interface implies. A mobile application typically contacts a dozen destinations — its own service, analytics, crash reporting, advertising, content delivery — and the transport policy applied to each is frequently not the same.
What an attacker is trying to achieve
The attacker is on the network: a shared wireless network, a hostile access point, or a compromised intermediary. They want to read or alter traffic, and they need only one channel that does not verify who it is speaking to.
Test cases
12 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
Android
Android's transport policy is declarative — a network security configuration in the package — so half of this is read statically and half confirmed on the device. Repackaging is available as well as instrumentation, and the user-versus-system trust anchor distinction changes what an intercepting proxy can do.
AND-TLS-01 Insecure Transport Layer Protocols
Objective — Determine whether any traffic leaves the device unprotected, including traffic from bundled components that do not follow the application's own transport policy.
How it is tested — Read the network security configuration from the package and record which domains permit cleartext and which trust anchors apply to each. Then capture traffic from a full pass through the application, including background synchronisation, analytics, crash reporting and web view content, and compare what the configuration permits against what actually occurs. Establish whether the application falls back to cleartext when a secured attempt fails.
Prerequisites — The decompiled package including its network security configuration; a proxy capturing every destination; a device able to run the application long enough for background traffic to occur.
Indicators — A cleartext permission in the configuration for a domain carrying data; plaintext traffic from a bundled component; fallback to cleartext on failure; traffic to a domain the configuration does not mention.
Coverage — MASVS-NETWORK-1V9.1.1CWE-319CWE-311
Depth — Hybrid Reading the configuration automates; establishing that observed traffic disagrees with it requires the capture.
AND-TLS-02 TLS Authenticity Flaws
Objective — Determine whether the application verifies the identity of the endpoint it connects to, on every channel and in every component.
How it is tested — Search the decompiled code for trust manager and hostname verifier implementations and identify any that accept everything. Then confirm behaviourally: present self-signed, expired, wrong-name and unknown-authority certificates in turn, with the proxy authority installed as a user certificate and then as a system certificate, since the trust anchors declared in the configuration decide which the application will accept.
Prerequisites — A proxy able to present arbitrary certificates; a device where a certificate can be installed both as a user and as a system anchor; the decompiled package.
Indicators — A permissive trust manager or hostname verifier in the package; a connection completing against an invalid certificate; validation differing between the application and a bundled component.
Coverage — MASVS-NETWORK-1V9.2.1CWE-295CWE-297
Depth — Manual The user-versus-system anchor distinction is specific to Android and has to be exercised both ways.
AND-TLS-03 TLS Weak Encryption
Objective — Determine which protocol versions and cipher suites the client will negotiate, given that the security provider varies with platform version.
How it is tested — Stand up a test endpoint offering specific protocol versions and suites, and record what the client accepts. Repeat across the range of platform versions the application supports, since the provider differs between them and an application supporting older releases inherits their defaults. Establish whether the application updates the security provider at startup, and what it negotiates when it does not.
Prerequisites — A test server able to offer specific combinations; devices or emulators covering the supported platform range; the manifest's minimum version.
Indicators — A deprecated protocol version negotiated on any supported release; a suite without forward secrecy accepted; no provider update where the supported range requires one.
Coverage — MASVS-NETWORK-1V9.1.2CWE-326CWE-327
Depth — Hybrid Negotiation testing automates once the server is standing; covering the supported platform range is the manual part.
AND-TLS-04 Bypassing Certificate Pinning
Objective — Determine whether pinning is implemented, whether it covers every channel, and what it costs an attacker holding the device to remove.
How it is tested — Establish which connections are pinned by attempting interception with the proxy authority trusted. Where pinning holds, defeat it two ways: by hooking the verification routines in the running application, and by repackaging with an altered network security configuration and re-signing — the second matters because it produces a persistently modified client rather than a runtime bypass. Establish whether pin failure fails closed.
Prerequisites — A device permitting instrumentation; repackaging and re-signing tooling; a proxy with a trusted authority; every traffic-producing feature exercisable.
Indicators — Pinning absent on some channels; pinning removed by editing the configuration and re-signing; a pin failure falling back to an unpinned connection; third-party traffic unpinned.
Coverage — MASVS-NETWORK-2MASVS-RESILIENCE-1CWE-295CWE-297
Depth — Manual The repackaging route is available on Android and is the one that produces a durable bypass, so it is tested as well as hooking.
AND-TLS-05 Known TLS Implementation Issues
Objective — Determine whether the transport implementation is exposed to published protocol and library weaknesses, including through a bundled stack.
How it is tested — Establish whether the application uses the platform's transport stack or bundles its own, and identify the version of any bundled library from the package. Compare against published advisories for that library. Separately, establish the negotiated protocol versions, compression settings and suites, and confirm whether the preconditions each published weakness requires are actually present rather than inferring from a version number.
Prerequisites — The decompiled package including native libraries; a test server able to negotiate specific combinations; advisory data.
Indicators — A bundled transport library materially behind current; a combination matching a published weakness; compression enabled on a channel carrying secrets.
Coverage — MASVS-NETWORK-1MASVS-CODE-3CWE-327CWE-1104
Depth — Hybrid Library inventory automates; confirming a weakness's preconditions are met is interpretation.
AND-TLS-06 Disabled Certificate Validation
Objective — Determine whether validation has been disabled anywhere, including in configuration intended only for debug builds.
How it is tested — Inspect the network security configuration for debug overrides, cleartext permissions and additional trust anchors, and establish whether any applies to the release build rather than only to a debuggable one. Search the code for trust managers and verifiers that accept everything, including in bundled components. Confirm behaviourally on every channel by presenting an invalid certificate, rather than relying on the review.
Prerequisites — The decompiled package and its configuration; a proxy able to present invalid certificates; a device running the release build.
Indicators — A debug override active in the release build; an additional trust anchor shipped; a permissive verifier reachable in release; an invalid certificate accepted on any channel.
Coverage — MASVS-NETWORK-1MASVS-CODE-1CWE-295CWE-297
Depth — Hybrid The configuration is readable statically; whether a debug override is live in the shipped build has to be confirmed on a device.
iOS
The equivalent policy is App Transport Security in the bundle, and its per-domain exceptions are the usual finding. Repackaging is impractical, so the pinning work is instrumentation, and custom trust evaluation lives in a session delegate rather than in configuration.
IOS-TLS-01 Insecure Transport Layer Protocols
Objective — Determine whether any traffic leaves the device unprotected, and whether the bundle declares exceptions that permit it.
How it is tested — Read the App Transport Security dictionary from the bundle and record every exception: arbitrary loads, per-domain exceptions, and the separate allowances for web content and media. Then capture traffic from a full pass through the application, including background refresh, analytics and crash reporting, and compare what the declaration permits against what occurs. Establish whether any exception is broader than the destination that motivated it.
Prerequisites — The application bundle and its transport security declaration; a proxy capturing every destination; a device able to run background refresh.
Indicators — Arbitrary loads permitted; a per-domain exception covering more than it needs; plaintext traffic from a bundled component; a media or web exception used for ordinary data traffic.
Coverage — MASVS-NETWORK-1V9.1.1CWE-319CWE-311
Depth — Hybrid Reading the declaration automates; establishing that an exception is wider than its purpose is a judgement.
IOS-TLS-02 TLS Authenticity Flaws
Objective — Determine whether the application verifies the identity of the endpoint it reaches, including where it implements its own trust evaluation.
How it is tested — Identify in the decrypted binary any session delegate implementing an authentication challenge handler, since that is where custom trust evaluation lives and where it is most often weakened. Then confirm behaviourally: present self-signed, expired, wrong-name and unknown-authority certificates in turn, with the proxy authority installed and trusted and then removed, and record which the application accepts on each channel.
Prerequisites — A proxy able to present arbitrary certificates; a device where a certificate profile can be installed and fully trusted, then removed; the decrypted binary.
Indicators — A challenge handler that accepts any server trust; a connection completing against an invalid certificate; validation differing between the application and an embedded web view.
Coverage — MASVS-NETWORK-1V9.2.1CWE-295CWE-297
Depth — Manual Custom trust evaluation lives in a delegate method, so the binary has to be read as well as the behaviour observed.
IOS-TLS-03 TLS Weak Encryption
Objective — Determine which protocol versions and cipher suites the client will accept, and whether transport security exceptions relax the platform's own minimums.
How it is tested — Stand up a test endpoint offering specific protocol versions and suites and record what the client accepts. Compare against the minimum the platform enforces by default, and establish whether any per-domain exception lowers that minimum — the transport security declaration can permit older protocol versions and weaker forward-secrecy requirements per domain, which is the usual route to a weak negotiation on this platform.
Prerequisites — A test server able to offer specific combinations; the bundle's transport security declaration; a device.
Indicators — A per-domain exception lowering the minimum protocol version; forward secrecy waived for a domain; a deprecated version negotiated; an exception applying to a domain carrying account data.
Coverage — MASVS-NETWORK-1V9.1.2CWE-326CWE-327
Depth — Hybrid Negotiation testing automates; reading which exception lowered which minimum is the manual part.
IOS-TLS-04 Bypassing Certificate Pinning
Objective — Determine whether pinning is implemented, whether it covers every channel, and what removing it costs an attacker holding the device.
How it is tested — Establish which connections are pinned by attempting interception with the proxy authority installed and fully trusted. Where pinning holds, defeat it by hooking the trust evaluation and the pinning library's own verification in the running application. Establish whether pinning is applied to web view and third-party traffic as well as the application's own, and whether a pin failure fails closed or falls back.
Prerequisites — A device permitting instrumentation of the running application; a proxy with a fully trusted authority; every traffic-producing feature exercisable.
Indicators — Pinning absent on some channels; pinning defeated by hooking without detection; a pin failure falling back to an unpinned connection; web view traffic unpinned.
Coverage — MASVS-NETWORK-2MASVS-RESILIENCE-1CWE-295CWE-297
Depth — Manual Repackaging is impractical here, so instrumentation is the route, and it must be run against each channel separately.
IOS-TLS-05 Known TLS Implementation Issues
Objective — Determine whether the transport implementation is exposed to published weaknesses, particularly where a third-party networking library is embedded.
How it is tested — Establish whether the application uses the platform's own networking or embeds a third-party library, and identify the version of any embedded one from the decrypted binary. Compare against published advisories. Separately, establish the negotiated protocol versions and suites and confirm whether the preconditions of each published weakness are actually present, rather than inferring exposure from a version number alone.
Prerequisites — A decrypted binary and disassembler; a test server able to negotiate specific combinations; advisory data.
Indicators — An embedded networking library materially behind current; a combination matching a published weakness; a library shipping its own trust store rather than using the system's.
Coverage — MASVS-NETWORK-1MASVS-CODE-3CWE-327CWE-1104
Depth — Hybrid Library identification automates once the binary is decrypted; confirming preconditions is interpretation.
IOS-TLS-06 Disabled Certificate Validation
Objective — Determine whether validation has been disabled anywhere, whether by a transport security exception or by code that accepts any server trust.
How it is tested — Inspect the bundle's transport security declaration for arbitrary loads and per-domain exceptions, and establish whether each is justified by a destination that genuinely requires it. Search the decrypted binary for challenge handlers that accept server trust unconditionally, including inside embedded libraries. Confirm on every channel by presenting an invalid certificate rather than relying on the review.
Prerequisites — The bundle and decrypted binary; a proxy able to present invalid certificates; a device running the shipped build.
Indicators — Arbitrary loads permitted in the shipped bundle; an exception with no corresponding destination; a handler accepting any server trust; an invalid certificate accepted on any channel.
Coverage — MASVS-NETWORK-1MASVS-CODE-1CWE-295CWE-273
Depth — Hybrid The declaration is readable statically; whether a permissive handler is reachable in the shipped build has to be confirmed on a device.
What we need from you
A proxy able to intercept and to present arbitrary certificates; a device on which the proxy's authority can be installed and removed independently; the ability to instrument the running application for the pinning cases; and every traffic-producing feature exercisable, including background work.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- MASVS-NETWORK-1 — The app secures all network traffic according to the current best practices.
- V9.1.1 — Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications.
- CWE-319 — Cleartext Transmission of Sensitive Information
- CWE-311 — Missing Encryption of Sensitive Data
- V9.2.1 — Verify that connections to and from the server use trusted TLS certificates. Where internally generated or self-signed certificates are used, the server must be configured to only trust specific internal CAs and specific self-signed certificates. All others should be rejected.
- CWE-295 — Improper Certificate Validation
- CWE-297 — Improper Validation of Certificate with Host Mismatch
- V9.1.2 — Verify using up to date TLS testing tools that only strong cipher suites are enabled, with the strongest cipher suites set as preferred.
- CWE-326 — Inadequate Encryption Strength
- CWE-327 — Use of a Broken or Risky Cryptographic Algorithm
- MASVS-NETWORK-2 — The app performs identity pinning for all remote endpoints under the developer's control.
- MASVS-RESILIENCE-1 — The app validates the integrity of the platform.
- MASVS-CODE-3 — The app only uses software components without known vulnerabilities.
- CWE-1104 — Use of Unmaintained Third Party Components
- MASVS-CODE-1 — The app requires an up-to-date platform version.
- CWE-273 — Improper Check for Dropped Privileges
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.