Vercel Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In Vercel a Team is the complete environment that belongs a client and a project is an application.
For a hardening review of Vercel you need to ask for a user with Viewer role permission or at least Project viewer permission over the projects to check (in case you only need to check the projects and not the Team configuration also).
Purpose: Manage fundamental project settings such as project name, framework, and build configurations.
Transfer
Misconfiguration: Allows to transfer the project to another team
Risk: An attacker could steal the project
Delete Project
Misconfiguration: Allows to delete the project
Risk: Delete the prject
Purpose: Manage custom domains, DNS settings, and SSL configurations.
DNS Configuration Errors
Misconfiguration: Incorrect DNS records (A, CNAME) pointing to malicious servers.
Risk: Domain hijacking, traffic interception, and phishing attacks.
SSL/TLS Certificate Management
Misconfiguration: Using weak or expired SSL/TLS certificates.
Risk: Vulnerable to man-in-the-middle (MITM) attacks, compromising data integrity and confidentiality.
DNSSEC Implementation
Misconfiguration: Failing to enable DNSSEC or incorrect DNSSEC settings.
Risk: Increased susceptibility to DNS spoofing and cache poisoning attacks.
Environment used per domain
Misconfiguration: Change the environment used by the domain in production.
Risk: Expose potential secrets or functionalities taht shouldn't be available in production.
Purpose: Define different environments (Development, Preview, Production) with specific settings and variables.
Environment Isolation
Misconfiguration: Sharing environment variables across environments.
Risk: Leakage of production secrets into development or preview environments, increasing exposure.
Access to Sensitive Environments
Misconfiguration: Allowing broad access to production environments.
Risk: Unauthorized changes or access to live applications, leading to potential downtimes or data breaches.
Purpose: Manage environment-specific variables and secrets used by the application.
Exposing Sensitive Variables
Misconfiguration: Prefixing sensitive variables with NEXT_PUBLIC_, making them accessible on the client side.
Risk: Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
Sensitive disabled
Misconfiguration: If disabled (default) it's possible to read the values of the generated secrets.
Risk: Increased likelihood of accidental exposure or unauthorized access to sensitive information.
Shared Environment Variables
Misconfiguration: These are env variables set at Team level and could also contain sensitive information.
Risk: Increased likelihood of accidental exposure or unauthorized access to sensitive information.
Purpose: Configure Git repository integrations, branch protections, and deployment triggers.
Ignored Build Step (TODO)
Misconfiguration: It looks like this option allows to configure a bash script/commands that will be executed when a new commit is pushed in Github, which could allow RCE.
Risk: TBD
Purpose: Connect third-party services and tools to enhance project functionalities.
Insecure Third-Party Integrations
Misconfiguration: Integrating with untrusted or insecure third-party services.
Risk: Introduction of vulnerabilities, data leaks, or backdoors through compromised integrations.
Over-Permissioned Integrations
Misconfiguration: Granting excessive permissions to integrated services.
Risk: Unauthorized access to project resources, data manipulation, or service disruptions.
Lack of Integration Monitoring
Misconfiguration: Failing to monitor and audit third-party integrations.
Risk: Delayed detection of compromised integrations, increasing the potential impact of security breaches.
Purpose: Secure deployments through various protection mechanisms, controlling who can access and deploy to your environments.
Vercel Authentication
Misconfiguration: Disabling authentication or not enforcing team member checks.
Risk: Unauthorized users can access deployments, leading to data breaches or application misuse.
Protection Bypass for Automation
Misconfiguration: Exposing the bypass secret publicly or using weak secrets.
Risk: Attackers can bypass deployment protections, accessing and manipulating protected deployments.
Shareable Links
Misconfiguration: Sharing links indiscriminately or failing to revoke outdated links.
Risk: Unauthorized access to protected deployments, bypassing authentication and IP restrictions.
OPTIONS Allowlist
Misconfiguration: Allowlisting overly broad paths or sensitive endpoints.
Risk: Attackers can exploit unprotected paths to perform unauthorized actions or bypass security checks.
Password Protection
Misconfiguration: Using weak passwords or sharing them insecurely.
Risk: Unauthorized access to deployments if passwords are guessed or leaked.
Note: Available on the Pro plan as part of Advanced Deployment Protection for an additional $150/month.
Deployment Protection Exceptions
Misconfiguration: Adding production or sensitive domains to the exception list inadvertently.
Risk: Exposure of critical deployments to the public, leading to data leaks or unauthorized access.
Note: Available on the Pro plan as part of Advanced Deployment Protection for an additional $150/month.
Trusted IPs
Misconfiguration: Incorrectly specifying IP addresses or CIDR ranges.
Risk: Legitimate users being blocked or unauthorized IPs gaining access.
Note: Available on the Enterprise plan.
Purpose: Configure serverless functions, including runtime settings, memory allocation, and security policies.
Nothing
Purpose: Manage caching strategies and settings to optimize performance and control data storage.
Purge Cache
Misconfiguration: It allows to delete all the cache.
Risk: Unauthorized users deleting the cache leading to a potential DoS.
Purpose: Schedule automated tasks and scripts to run at specified intervals.
Disable Cron Job
Misconfiguration: It allows to disable cron jobs declared inside the code
Risk: Potential interruption of the service (depending on what the cron jobs were meant for)
Purpose: Configure external logging services to capture and store application logs for monitoring and auditing.
Nothing (managed from teams settings)
Purpose: Central hub for various security-related settings affecting project access, source protection, and more.
Build Logs and Source Protection
Misconfiguration: Disabling protection or exposing /logs and /src paths publicly.
Risk: Unauthorized access to build logs and source code, leading to information leaks and potential exploitation of vulnerabilities.
Git Fork Protection
Misconfiguration: Allowing unauthorized pull requests without proper reviews.
Risk: Malicious code can be merged into the codebase, introducing vulnerabilities or backdoors.
Secure Backend Access with OIDC Federation
Misconfiguration: Incorrectly setting up OIDC parameters or using insecure issuer URLs.
Risk: Unauthorized access to backend services through flawed authentication flows.
Deployment Retention Policy
Misconfiguration: Setting retention periods too short (losing deployment history) or too long (unnecessary data retention).
Risk: Inability to perform rollbacks when needed or increased risk of data exposure from old deployments.
Recently Deleted Deployments
Misconfiguration: Not monitoring deleted deployments or relying solely on automated deletions.
Risk: Loss of critical deployment history, hindering audits and rollbacks.
Purpose: Access to additional project settings for fine-tuning configurations and enhancing security.
Directory Listing
Misconfiguration: Enabling directory listing allows users to view directory contents without an index file.
Risk: Exposure of sensitive files, application structure, and potential entry points for attacks.
Enable Attack Challenge Mode
Misconfiguration: Enabling this improves the defenses of the web application against DoS but at the cost of usability
Risk: Potential user experience problems.
Misconfiguration: Allows to unblock/block traffic
Risk: Potential DoS allowing malicious traffic or blocking benign traffic
Misconfiguration: Allows access to read the complete source code of the application
Risk: Potential exposure of sensitive information
Misconfiguration: This protection ensures the client and server application are always using the same version so there is no desynchronizations were the client uses a different version from the server and therefore they don't understand each other.
Risk: Disabling this (if enabled) could cause DoS problems in new deployments in the future
Transfer
Misconfiguration: Allows to transfer all the projects to another team
Risk: An attacker could steal the projects
Delete Project
Misconfiguration: Allows to delete the team with all the projects
Risk: Delete the projects
Speed Insights Cost Limit
Misconfiguration: An attacker could increase this number
Risk: Increased costs
Add members
Misconfiguration: An attacker could maintain persitence inviting an account he control
Risk: Attacker persistence
Roles
Misconfiguration: Granting too many permissions to people that doesn't need it increases the risk of the vercel configuration. Check all the possible roles in https://vercel.com/docs/accounts/team-members-and-roles/access-roles
Risk: Increate the exposure of the Vercel Team
An Access Group in Vercel is a collection of projects and team members with predefined role assignments, enabling centralized and streamlined access management across multiple projects.
Potential Misconfigurations:
Over-Permissioning Members: Assigning roles with more permissions than necessary, leading to unauthorized access or actions.
Improper Role Assignments: Incorrectly assigning roles that do not align with team members' responsibilities, causing privilege escalation.
Lack of Project Segregation: Failing to separate sensitive projects, allowing broader access than intended.
Insufficient Group Management: Not regularly reviewing or updating Access Groups, resulting in outdated or inappropriate access permissions.
Inconsistent Role Definitions: Using inconsistent or unclear role definitions across different Access Groups, leading to confusion and security gaps.
Log Drains to third parties:
Misconfiguration: An attacker could configure a Log Drain to steal the logs
Risk: Partial persistence
Team Email Domain: When configured, this setting automatically invites Vercel Personal Accounts with email addresses ending in the specified domain (e.g., mydomain.com) to join your team upon signup and on the dashboard.
Misconfiguration:
Specifying the wrong email domain or a misspelled domain in the Team Email Domain setting.
Using a common email domain (e.g., gmail.com, hotmail.com) instead of a company-specific domain.
Risks:
Unauthorized Access: Users with email addresses from unintended domains may receive invitations to join your team.
Data Exposure: Potential exposure of sensitive project information to unauthorized individuals.
Protected Git Scopes: Allows you to add up to 5 Git scopes to your team to prevent other Vercel teams from deploying repositories from the protected scope. Multiple teams can specify the same scope, allowing both teams access.
Misconfiguration: Not adding critical Git scopes to the protected list.
Risks:
Unauthorized Deployments: Other teams may deploy repositories from your organization's Git scopes without authorization.
Intellectual Property Exposure: Proprietary code could be deployed and accessed outside your team.
Environment Variable Policies: Enforces policies for the creation and editing of the team's environment variables. Specifically, you can enforce that all environment variables are created as Sensitive Environment Variables, which can only be decrypted by Vercel's deployment system.
Misconfiguration: Keeping the enforcement of sensitive environment variables disabled.
Risks:
Exposure of Secrets: Environment variables may be viewed or edited by unauthorized team members.
Data Breach: Sensitive information like API keys and credentials could be leaked.
Audit Log: Provides an export of the team's activity for up to the last 90 days. Audit logs help in monitoring and tracking actions performed by team members.
Misconfiguration: Granting access to audit logs to unauthorized team members.
Risks:
Privacy Violations: Exposure of sensitive user activities and data.
Tampering with Logs: Malicious actors could alter or delete logs to cover their tracks.
SAML Single Sign-On: Allows customization of SAML authentication and directory syncing for your team, enabling integration with an Identity Provider (IdP) for centralized authentication and user management.
Misconfiguration: An attacker could backdoor the Team setting up SAML parameters such as Entity ID, SSO URL, or certificate fingerprints.
Risk: Maintain persistence
IP Address Visibility: Controls whether IP addresses, which may be considered personal information under certain data protection laws, are displayed in Monitoring queries and Log Drains.
Misconfiguration: Leaving IP address visibility enabled without necessity.
Risks:
Privacy Violations: Non-compliance with data protection regulations like GDPR.
Legal Repercussions: Potential fines and penalties for mishandling personal data.
IP Blocking: Allows the configuration of IP addresses and CIDR ranges that Vercel should block requests from. Blocked requests do not contribute to your billing.
Misconfiguration: Could be abused by an attacker to allow malicious traffic or block legit traffic.
Risks:
Service Denial to Legitimate Users: Blocking access for valid users or partners.
Operational Disruptions: Loss of service availability for certain regions or clients.
Vercel Secure Compute enables secure, private connections between Vercel Functions and backend environments (e.g., databases) by establishing isolated networks with dedicated IP addresses. This eliminates the need to expose backend services publicly, enhancing security, compliance, and privacy.
Incorrect AWS Region Selection
Misconfiguration: Choosing an AWS region for the Secure Compute network that doesn't match the backend services' region.
Risk: Increased latency, potential data residency compliance issues, and degraded performance.
Overlapping CIDR Blocks
Misconfiguration: Selecting CIDR blocks that overlap with existing VPCs or other networks.
Risk: Network conflicts leading to failed connections, unauthorized access, or data leakage between networks.
Improper VPC Peering Configuration
Misconfiguration: Incorrectly setting up VPC peering (e.g., wrong VPC IDs, incomplete route table updates).
Risk: Unauthorized access to backend infrastructure, failed secure connections, and potential data breaches.
Excessive Project Assignments
Misconfiguration: Assigning multiple projects to a single Secure Compute network without proper isolation.
Risk: Shared IP exposure increases the attack surface, potentially allowing compromised projects to affect others.
Inadequate IP Address Management
Misconfiguration: Failing to manage or rotate dedicated IP addresses appropriately.
Risk: IP spoofing, tracking vulnerabilities, and potential blacklisting if IPs are associated with malicious activities.
Including Build Containers Unnecessarily
Misconfiguration: Adding build containers to the Secure Compute network when backend access isn't required during builds.
Risk: Expanded attack surface, increased provisioning delays, and unnecessary consumption of network resources.
Failure to Securely Handle Bypass Secrets
Misconfiguration: Exposing or mishandling secrets used to bypass deployment protections.
Risk: Unauthorized access to protected deployments, allowing attackers to manipulate or deploy malicious code.
Ignoring Region Failover Configurations
Misconfiguration: Not setting up passive failover regions or misconfiguring failover settings.
Risk: Service downtime during primary region outages, leading to reduced availability and potential data inconsistency.
Exceeding VPC Peering Connection Limits
Misconfiguration: Attempting to establish more VPC peering connections than the allowed limit (e.g., exceeding 50 connections).
Risk: Inability to connect necessary backend services securely, causing deployment failures and operational disruptions.
Insecure Network Settings
Misconfiguration: Weak firewall rules, lack of encryption, or improper network segmentation within the Secure Compute network.
Risk: Data interception, unauthorized access to backend services, and increased vulnerability to attacks.
Purpose: Manage environment-specific variables and secrets used by all the projects.
Exposing Sensitive Variables
Misconfiguration: Prefixing sensitive variables with NEXT_PUBLIC_, making them accessible on the client side.
Risk: Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
Sensitive disabled
Misconfiguration: If disabled (default) it's possible to read the values of the generated secrets.
Risk: Increased likelihood of accidental exposure or unauthorized access to sensitive information.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
