Checks

Vercel API tokens are assessed for staleness by checking whether each token has been active within the last 90 days. Stale tokens that remain unused for extended periods represent unnecessary access credentials that increase the attack surface. Tokens with no recorded activity are also flagged.

Vercel API tokens are assessed for expiration status to identify expired tokens or those about to expire within a configurable threshold (default: 7 days). Tokens about to expire are flagged proactively so they can be rotated before causing disruptions. Tokens without an expiration date are considered valid.

Vercel production deployments are assessed for source branch stability by verifying they are sourced from a stable branch (main or master). Deploying to production from feature branches bypasses standard CI/CD review processes and may introduce untested or incomplete code into the production environment.

Vercel domains are assessed for DNS configuration to verify records properly point to Vercel's infrastructure. Misconfigured DNS can result in domains that fail to serve content, SSL certificate provisioning failures, and degraded user experience.

Vercel domains are assessed for SSL certificate validity including provisioning, expiration, and upcoming expiry. Vercel automatically provisions and renews SSL certificates for properly configured domains. A missing, expired, or soon-to-expire certificate indicates a configuration issue that may leave traffic unencrypted.

Vercel domains are assessed for ownership verification status. Unverified domains may not serve traffic correctly and could indicate a pending or incomplete domain setup. Domain verification confirms that the domain owner has authorized Vercel to manage the domain.

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.

Vercel projects are assessed for production deployment protection configuration, which restricts access to the live production deployment by requiring Vercel Authentication or other access controls. When enabled, visitors must authenticate before accessing the production URL, adding a layer of defense for internal applications or projects that should not be publicly accessible.

Vercel projects are assessed for skew protection, which ensures clients always communicate with the correct deployment version during rollouts. Without it, clients may fetch assets or call APIs against a different version than the one that served the initial page, causing hydration errors or broken functionality.

Vercel projects are assessed for custom firewall rule configuration. Custom rules allow fine-grained control over traffic based on request attributes such as path, headers, user agent, and geographic location, providing application-specific protection beyond managed rulesets.

Vercel projects are assessed for IP blocking rule configuration. IP blocking rules allow denying access from known malicious IP addresses or ranges, reducing the attack surface and preventing traffic from untrusted sources.

Vercel projects are assessed for managed WAF ruleset enablement. Managed rulesets are curated by Vercel and provide protection against known attack patterns including OWASP Top 10 threats. Availability varies by ruleset, and the check reports MANUAL when the firewall configuration cannot be assessed from the API.

Vercel projects are assessed for rate limiting rule configuration. Rate limiting protects applications from abuse, brute-force attacks, and DDoS attempts by restricting the number of requests from a single source within a given time window.

Vercel projects are assessed for Web Application Firewall (WAF) enablement. The WAF provides protection against common web attacks including SQL injection, cross-site scripting (XSS), and other OWASP Top 10 threats.

Vercel team is assessed for directory sync (SCIM) enablement. Directory sync automates user provisioning and deprovisioning by synchronizing team membership with an external identity provider, ensuring timely access revocation when employees leave.

Vercel team members are assessed for least privilege by checking whether the proportion of members with the OWNER role exceeds a configurable percentage threshold (default: 20%) or a maximum owner count (default: 3). Both thresholds are configurable via audit_config. An excessive number of owners increases the attack surface and risk of accidental or malicious configuration changes.

Vercel team is assessed for stale invitations by checking whether pending invitations have been outstanding for more than 30 days. Stale invitations may indicate abandoned onboarding processes or forgotten invitation links that could be exploited.