Checks
Browse individual security checks available in the Prowler Registry. Filter by cloud provider, severity, or search by check ID.
Browse individual security checks available in the Prowler Registry. Filter by cloud provider, severity, or search by check ID.
awslambda_function_no_secrets_in_code
Lambda function code is analyzed for embedded secrets across files in the deployment package, detecting patterns like API keys, passwords, tokens, and connection strings. Findings reference file names and line numbers where potential secrets appear.
awslambda_function_no_secrets_in_variables
AWS Lambda function environment variables are analyzed for content that resembles secrets (API keys, tokens, passwords). Pattern-based detection highlights potential hardcoded credentials present in the function's environment.
awslambda_function_not_publicly_accessible
AWS Lambda function resource-based policies are assessed for public access. The finding identifies policies with wildcard or empty Principal that allow actions like lambda:InvokeFunction to any principal.
awslambda_function_url_cors_policy
Lambda function URL CORS policy is reviewed for AllowOrigins. The presence of * indicates a wide origin allowance in the CORS configuration.
awslambda_function_url_public
AWS Lambda function URLs are assessed to determine whether AuthType enforces AWS IAM authentication or permits public invocation.
Applies to functions with a function URL and highlights when requests must be authenticated and authorized via IAM principals.
awslambda_function_using_cross_account_layers
AWS Lambda functions use only layers published within the same AWS account, rather than layers owned by external accounts.
A Lambda layer bundles shared code or dependencies that are injected into the function execution environment at runtime.
awslambda_function_using_supported_runtimes
Lambda functions using obsolete runtimes-such as python3.8, nodejs14.x, go1.x, ruby2.7-are identified against a curated list of deprecated runtime identifiers.
awslambda_function_vpc_multi_az
AWS Lambda functions attached to a VPC use subnets that span at least the required number of Availability Zones (2 by default).
The evaluation counts the unique AZs of the function's configured subnets.
awslambda_layer_no_secrets_in_content
Lambda layer content is analyzed for embedded secrets across files in the layer's package, detecting patterns like API keys, passwords, tokens, and connection strings. Findings reference file names and line numbers where potential secrets appear.
The TLS mutual authentication technique in enterprise environments ensures the authenticity of clients to the server. If incoming client certificates are enabled only an authenticated client with valid certificates can access the app.
Registering the identity used by an App with AD allows it to interact with other services without using username and password
Enabling authentication ensures that all communications in the application are authenticated. The auth_settings block needs to be filled out with the appropriate auth backend settings
By default, clients can connect to function endpoints by using both HTTP or HTTPS. You should redirect HTTP to HTTPs because HTTPS uses the SSL/TLS protocol to provide a secure connection, which is both encrypted and authenticated.
Use the latest version of HTTP to ensure you are benefiting from security fixes
AZU-0006
Use a more recent TLS/SSL policy for the App Service
Storage container public access should be off. It can be configured for blobs only, containers and blobs or off entirely. The default is off, with no public access. Explicitly overriding publicAccess to anything other than off should be avoided.
You can configure your storage account to accept requests from secure connections only by setting the Secure transfer required property for the storage account. When you require secure transfer, any requests originating from an insecure connection are rejected. Microsoft recommends that you always require secure transfer for all of your storage accounts.
Storage Analytics logs detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service. Requests are logged on a best-effort basis.
Some Microsoft services that interact with storage accounts operate from networks that can't be granted access through network rules. To help this type of service work as intended, allow the set of trusted Microsoft services to bypass the network rules
Azure Storage supports four versions of the TLS protocol: 1.0, 1.1, 1.2, and 1.3. Azure Storage uses TLS 1.2 or TLS 1.3 on public HTTPS endpoints, while TLS 1.0 and TLS 1.1 are still supported for backward compatibility. This check will warn if the minimum TLS version is set lower than TLS1_2. TLS1_2 and TLS1_3 are both allowed.
The default_action for network rules should come into effect when no other rules are matched. The default action should be set to Deny.
Network ACLs allow you to reduce your exposure to risk by limiting what can access your key vault.
The default action of the Network ACL should be set to deny for when IPs are not matched. Azure services can be allowed to bypass.
Expiration Date is an optional Key Vault Key behavior and is not set by default.
Set when the resource will be become inactive.
Content Type is an optional Key Vault Secret behavior and is not enabled by default.
Clients may specify the content type of a secret to assist in interpreting the secret data when it's retrieved. The maximum length of this field is 255 characters. There are no pre-defined values. The suggested usage is as a hint for interpreting the secret data.