Checks

Alibaba Cloud OSS Bucket Access Logging generates a log record for each request made to your OSS bucket, containing details such as the request type, the resources specified, and the time and date the request was processed. Enabling bucket access logging on all OSS buckets ensures that access patterns are recorded and available for security analysis and incident response workflows.

Alibaba Cloud Object Storage Service (OSS) buckets store objects that may contain sensitive data. It is recommended that the access policy on OSS buckets does not allow anonymous or public access, ensuring that only authorized identities can interact with bucket contents. The bucket ACL should be set to private to prevent unintended data exposure.

Alibaba Cloud OSS buckets should enforce secure transfer by requiring all requests to use HTTPS. A bucket policy that denies requests with acs:SecureTransport set to false ensures that data in transit is encrypted, rejecting any unencrypted HTTP connections to the storage endpoint.

Alibaba Cloud OSS buckets should define a default server-side encryption rule so every newly uploaded object is encrypted at rest with SSE-OSS (AES256) or SSE-KMS (KMS) without relying on per-request headers.

Alibaba Cloud OSS Bucket Versioning stores previous versions of objects when they are overwritten or deleted, allowing any version to be restored at a later time. Enabling versioning on all OSS buckets ensures that data can be recovered after unintended changes or deletions.

Defender for Cloud default policy assignment (SecurityCenterBuiltIn) uses enforcement mode Default rather than DoNotEnforce

Azure Database for PostgreSQL Flexible Server firewall should not include the rule that allows connections from any Azure service, represented by start_ip=0.0.0.0 and end_ip=0.0.0.0.

Azure PostgreSQL flexible servers where the connection_throttling parameter is set to ON

Azure Database for PostgreSQL flexible servers are evaluated for encrypted in-transit connections, specifically whether require_secure_transport is set to ON to force TLS for all client sessions.

PostgreSQL Flexible Servers must set authConfig.activeDirectoryAuth to Enabled and keep at least one Microsoft Entra administrator assigned so database sessions inherit centrally governed identities instead of unmanaged PostgreSQL accounts.

Azure PostgreSQL Flexible Server is evaluated for geo-redundant backup. Geo-redundant backup stores backup copies in a paired Azure region, enabling restore and cross-region disaster recovery.

Azure PostgreSQL Flexible Server is evaluated for high availability mode. Zone-redundant or same-zone HA provisions a standby replica and provides automatic failover during planned and unplanned outages.

Azure PostgreSQL Flexible Server has checkpoint logging enabled when log_checkpoints=on, recording each checkpoint in the server logs

Azure Database for PostgreSQL Flexible Server evaluates the log_connections setting that controls logging of client connection attempts and authentication results.

The finding indicates whether this parameter is set to ON.

Azure Database for PostgreSQL Flexible Server uses the log_disconnections setting to record when client sessions end and how long they lasted.

Log retention on Azure Database for PostgreSQL Flexible Server is governed by log_retention_days. Configuration is assessed as set and within 4-7 days versus unset or outside this range.

Vercel projects are assessed for automatic system environment variable exposure (VERCEL_URL, VERCEL_ENV, VERCEL_GIT_COMMIT_SHA). When enabled, these variables are injected into every deployment and may be accessible in client-side JavaScript bundles if not handled carefully, leaking internal infrastructure details.

Vercel projects are assessed for deployment protection configuration, which restricts access to preview deployments by requiring authentication before visitors can view them. When disabled, anyone with the preview URL can access in-progress or staging versions of the application, potentially exposing unreleased features, debug information, or internal endpoints.

Vercel projects are assessed for directory listing configuration. When enabled, this feature allows visitors to browse the file structure of a deployment when no index file is present in a directory, potentially exposing source files, configuration files, and other assets that should not be publicly accessible.

Vercel project environment variables are assessed for overly broad targeting by checking whether any variable targets all three environments (production, preview, development) simultaneously, which violates the principle of least privilege.

Vercel project environment variables are assessed for secret exposure by checking whether variables with secret-like name suffixes (*_KEY, *_SECRET, *_TOKEN, *_PASSWORD, *_API_KEY, *_PRIVATE_KEY) are stored using the plain type, which makes their values readable.

Vercel project environment variables are assessed for environment separation by checking whether sensitive variables (type secret or encrypted) that target the production environment also target preview, which could expose production credentials to untrusted preview builds.

Vercel projects are assessed for Git fork protection configuration, which controls whether pull requests from forked repositories can trigger deployments and access environment variables. When disabled, anyone who forks a public repository can submit a pull request that triggers a Vercel build with access to the project's environment variables, including secrets and API keys.

Vercel projects are assessed for password protection configuration, which adds a shared-password gate in front of deployments requiring visitors to enter a password before they can access the application. This provides an additional layer of access control beyond Vercel Authentication, useful for sharing preview deployments with external stakeholders who do not have Vercel accounts.