Configuration setting that disables transport or storage cryptography

unsafe_crypto_setting_in_config

Severity

high

Remediation Complexity

trivial

Remediation Risk

medium

Remediation Effort

low

Family

Cryptography

Description

Some configuration keys do not weaken cryptography, they switch it off. This detector reports the ones in the shipped catalogue when they are set to their unsafe value:

NSThirdPartyExceptionAllowsInsecureHTTPLoads — an iOS App Transport Security opt-out for a third-party domain, so those requests fall back to plain HTTP.
NSExceptionRequiresForwardSecrecy = false — an exception domain no longer needs a forward-secret suite.
certificates src="user" — the app trusts the device’s user CA store, which an interception proxy installs into.
SECURE_SSL_REDIRECT = False, SESSION_COOKIE_SECURE = False, config.force_ssl = false, session.cookie_secure = 0 — the framework stops requiring TLS.
passwordFormat="Clear" and forms protection="None" — ASP.NET stores or transmits credentials unprotected.
server.ssl.key-store-type=JKS — the proprietary key store format, whose integrity protection is a SHA-1 HMAC over a password-derived key.
Switch.System.Net.DontEnableSchUseStrongCrypto=true — .NET reverts to the pre-4.6 protocol defaults, re-enabling SSL 3.0 and TLS 1.0 process-wide.
<transport-guarantee>NONE</transport-guarantee> — the servlet container may serve a constrained resource over cleartext.
A JOSE algorithm set to none — spring.security.oauth2.resourceserver.jwt.jws-algorithms, a JWT/token signature key, or alg in a published JWKS. The signature of a token becomes optional, so anyone can mint one with arbitrary claims. It names no algorithm, so it is reported here rather than inventoried as one.

Which value is unsafe is stated per key by the catalogue, because the polarity differs: Android’s certificates src="user" and Django’s SECURE_SSL_REDIRECT = False are both unsafe, written in opposite directions.

The Android and iOS plain-HTTP opt-outs — cleartextTrafficPermitted, android:usesCleartextTraffic, NSAllowsArbitraryLoads and its web-content, media and first-party exception variants — are deliberately not here. Existing SAST rules already report them (kotlin.android_insecure_transport_configuration, swift.insecure_transport, swift.ats_allows_arbitrary_loads_in_web_content, swift.ats_allows_arbitrary_loads_for_media, swift.ats_exception_insecure_http_loads), and covering them here as well produced two findings for one setting.

Unlike the other rules in this family, this one records no crypto.assetId, and cannot: a setting that disables transport security names no algorithm, protocol version or key material, so there is no crypto asset for the finding to link to.

Security

These settings defeat cryptography rather than degrading it. An App Transport Security opt-out means credentials, tokens and personal data cross the network readable by anything on the path — the captive network, the mobile carrier, a compromised router. A session cookie without Secure is sent over any plain-HTTP request to the same host, which is all an attacker needs to obtain it. Trusting the user CA store means the pinning and validation the rest of the app performs can be bypassed by any CA the device owner — or malware on the device — installed.

The pattern behind most of these findings is a debugging change that shipped. An ATS exception is added to talk to a local or partner server, and nothing later removes it.

Mitigation / Fix

Remove the opt-out, and scope it narrowly if a local exception is genuinely needed:

<!-- Android: trust the system store only, so a proxy CA on the device cannot terminate the app's TLS -->
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

# Django
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True

# Spring Boot: PKCS#12 rather than the proprietary formats
server.ssl.key-store-type=PKCS12

For the ASP.NET storage settings, passwordFormat="Hashed" is the only setting that survives a database disclosure, and protection="All" the only one that both encrypts and authenticates the forms ticket. Keep the development-only exceptions in a configuration profile that cannot ship — a debug build variant, a non-production Spring profile — rather than in the file the release reads.