Weak Password Requirements

Property
Languagepython
Severitylow
CWECWE-521: Weak Password Requirements
OWASPA07:2021 - Identification and Authentication Failures
Confidence LevelLow
Impact LevelMedium
Likelihood LevelLow

Description

Passwords are being set on user accounts without first validating their strength and complexity using Django’s password validation. This means weak or easily guessable passwords might be accepted.

Impact

If passwords are not properly validated, attackers or users could set weak passwords, making accounts much easier to compromise. This increases the risk of unauthorized access, data breaches, and could undermine the security of the entire application.

Weak Password Requirements

Property
Languagepython
Severitymedium
CWECWE-521: Weak Password Requirements
OWASPA07:2021 - Identification and Authentication Failures
Confidence LevelMedium
Impact LevelMedium
Likelihood LevelMedium

Description

Setting a user’s password to an empty string (’’) instead of None or using set_unusable_password() leaves the account with a blank but valid password. This makes it possible for anyone to log in without a password.

Impact

If exploited, attackers could gain unauthorized access to user accounts simply by submitting an empty password. This exposes sensitive user data and can compromise the security of the entire application.

Weak Password Requirements

Property
Languagepython
Severitymedium
CWECWE-521: Weak Password Requirements
OWASPA07:2021 - Identification and Authentication Failures
Confidence LevelMedium
Impact LevelMedium
Likelihood LevelLow

Description

Setting a user’s password to an empty string in Django makes the account easily guessable and insecure. Instead, use None or set_unusable_password() if you want to disable login for that user.

Impact

If a user has an empty string as their password, anyone can log in to their account by submitting a blank password. This can lead to unauthorized access, data breaches, and compromise of user accounts and sensitive information.

Web App accepts incoming client certificate

Property
Languageterraform
Severitylow
Serviceappservice
ProviderAzure

Description

The web application is configured without requiring incoming client certificates, meaning mutual TLS authentication is not enforced. This allows any client to connect without verifying their identity through a certificate.

Impact

Without client certificate validation, unauthorized clients can access the application, increasing the risk of data exposure and unauthorized actions. Attackers could exploit this to impersonate legitimate users or automate malicious access, reducing the overall security of the app.

Web App has registration with AD enabled

Property
Languageterraform
Severitylow
Serviceappservice
ProviderAzure

Description

The application service is not registered with Azure Active Directory (AD), so it lacks an assigned managed identity. Without this, the service cannot securely authenticate to other Azure resources without embedding credentials in code.

Impact

Failure to assign an identity forces the use of less secure authentication methods, such as hardcoded usernames and passwords, increasing the risk of credential leaks and unauthorized access to other Azure services.

Web App uses latest TLS version

Property
Languageterraform
Severityhigh
Serviceappservice
ProviderAzure
Vulnerability Typemisconfiguration

Description

The App Service is configured to allow outdated TLS versions (such as TLS 1.0 or 1.1), which have known security vulnerabilities. This exposes encrypted communications to potential interception or tampering.

Impact

Attackers could exploit weaknesses in older TLS protocols to decrypt sensitive data, perform man-in-the-middle attacks, or compromise user authentication, resulting in data breaches or unauthorized access to the application.

Web App uses the latest HTTP version

Property
Languageterraform
Severitylow
Serviceappservice
ProviderAzure

Description

The web application is configured to use an outdated HTTP version by not enabling HTTP/2 support in the Azure App Service resource. This prevents the app from benefiting from improved security features and protocol enhancements available in newer HTTP versions.

Impact

Running on an older HTTP version exposes the application to known vulnerabilities and lacks protections present in HTTP/2, increasing the risk of attacks such as protocol downgrade, interception, or performance degradation, which can compromise data integrity and service reliability.

When using Queue Services for a storage account, logging should be enabled.

Property
Languageterraform
Severitymedium
Servicestorage
ProviderAzure
Vulnerability Typeomission

Description

Queue services in the Azure storage account are configured without logging enabled, preventing the collection of detailed information about successful and failed requests. This omission limits visibility into service operations and access patterns.

Impact

Without logging, it is difficult to detect unauthorized access, investigate incidents, or troubleshoot issues related to the storage queue. This lack of audit data can hinder security monitoring and compromise the ability to respond to or recover from potential attacks or misconfigurations.

WORKDIR path not absolute

Property
Languageterraform
Severityhigh
Vulnerability Typeomission

Description

The Dockerfile uses a relative path for the WORKDIR instruction instead of an absolute path. This can lead to unpredictable working directory locations depending on the build context or previously set WORKDIRs, reducing clarity and reliability.

Impact

Using a non-absolute WORKDIR may cause applications or scripts within the container to run in unintended directories, increasing the risk of file access errors, misconfigurations, or accidental overwriting of files. This can lead to unstable builds, potential data loss, or security missteps within containerized environments.

WORKDIR should not be mounted on system dirs

Property
Languageterraform
Severityhigh

Description

The WORKDIR in the container is set to a critical system directory (e.g., /proc/, /boot/, /dev/), which exposes sensitive parts of the host or container filesystem to application processes. This configuration breaks isolation and increases the risk of container escape.

Impact

An attacker could manipulate or overwrite system files, potentially gaining elevated privileges, accessing sensitive data, or compromising the host system. This could lead to full container breakout, loss of data integrity, and severe security breaches affecting the entire infrastructure.