Cloud & Serverless
Cloud metadata, serverless, and platform APIs abused for credential theft and SSRF.
20 probed paths in this category.
.firebaserc
Firebase CLI project-alias configuration file
Risk: Discloses Firebase project IDs and deployment aliases, letting an attacker identify the exact backend project and probe its APIs and storage buckets.
Fix: Keep deployment config out of public hosting where possible, and rely on robust Firebase security rules and App Check rather than project-ID obscurity for protection.
api/v1/firebase/projects
Firebase Projects API
Risk: Exposure of Firebase project credentials or a service account would let an attacker read and write Firestore/Realtime Database data, manage Auth users, and invoke Cloud Functions across the project.
Fix: Enforce strict Firebase Security Rules instead of relying on obscurity, never ship admin service-account keys to clients, and restrict API keys by referrer/IP in the Google Cloud console.
aws-exports.js
AWS Amplify configuration file exposing backend resource identifiers
Risk: Exposes AWS Amplify backend identifiers such as Cognito pool IDs, API Gateway endpoints, and region details, giving an attacker a map of backend resources to probe for misconfigured auth.
Fix: Treat these as public client config but harden the backend: enforce Cognito auth, IAM least privilege, and proper API authorization so exposed identifiers cannot be abused.
cloud-config
Cloud-init cloud-config file used to provision instances
Risk: Reveals cloud-init provisioning configuration including package lists, users, and any inline credentials, helping an attacker understand and reproduce the instance setup.
Fix: Keep provisioning data out of web-accessible paths, reference secrets from a secrets manager rather than inline, and enforce IMDSv2 to prevent SSRF retrieval of metadata.
cloudflare/api/v4/zones
Cloudflare Zones API
Risk: A leaked Cloudflare API token or Global API Key would allow an attacker to alter DNS records, disable WAF/SSL, purge cache, or proxy traffic for every zone on the account, enabling domain takeover and traffic interception.
Fix: Replace the Global API Key with scoped API Tokens limited to specific zones and permissions, enforce IP allowlisting on tokens, and rotate credentials exposed in client-side code or logs.
cloudfunctions/execute
Google Cloud Functions Execution
Risk: A publicly executable Google Cloud Function lets attackers run it at will, abusing its service account permissions to reach GCP resources and incurring uncontrolled invocation costs.
Fix: Disable unauthenticated invocation, require IAM-based auth (Cloud Run/Functions invoker role), and grant the function's service account least-privilege scopes.
fastly/api/service
Fastly Service API
Risk: An exposed Fastly API token lets an attacker modify VCL/service configuration, reroute or poison cached content, and disable TLS, affecting all edge traffic for the service.
Fix: Use scoped Fastly API tokens with only the needed roles, restrict them by service and IP, and never embed tokens in front-end assets or commit them to version control.
firebase.json
Firebase project configuration file
Risk: Reveals Firebase hosting, rewrite, and deployment configuration that helps an attacker fingerprint your backend structure and locate functions or Firestore endpoints to target.
Fix: Although mostly non-secret, enforce strict Firestore/Storage security rules and App Check so exposed config cannot be leveraged, and avoid committing any secrets alongside it.
fly/api/v1/apps
Fly.io Apps API
Risk: A valid Fly.io API token would let an attacker list, deploy, restart, or destroy every Fly Machine and app in the organization, and read secrets injected into running apps.
Fix: Scope Fly.io tokens with `fly tokens create` to the minimum app/org, store them only in CI secret stores, and rotate any token that touches a public repo or build log.
functions/api/trigger
Azure Functions Trigger Endpoint
Risk: An unprotected Azure Functions trigger can be invoked by anyone, allowing abuse of the function's logic and its managed identity to access connected storage, queues, or databases.
Fix: Require function-level or AAD authentication, store the function key securely, and scope the function's managed identity to the minimum needed resources.
lambda/api/v1/invoke
AWS Lambda Invocation Endpoint
Risk: A directly invokable Lambda endpoint without authorization lets an attacker execute the function with arbitrary input, potentially abusing its IAM role to reach other AWS resources or run up costs.
Fix: Front Lambda with API Gateway authorizers or IAM auth, apply least-privilege execution roles, and validate all event input within the function.
latest/meta-data/
AWS EC2 Instance Metadata Service path, a classic SSRF target for stealing IAM credentials
Risk: This is the cloud instance-metadata endpoint. Through an SSRF flaw an attacker can reach it to steal temporary IAM credentials and pivot into the wider cloud account.
Fix: Enforce IMDSv2 (token-required) on EC2, lower the metadata hop limit, and validate or deny server-side requests to link-local addresses such as 169.254.169.254.
netlify/api/v1/sites
Netlify Sites API
Risk: A compromised Netlify token at this endpoint allows an attacker to enumerate sites, read build environment variables and deploy keys, and trigger malicious deploys or DNS changes that hijack the served content.
Fix: Restrict personal access token scope and rotate leaked tokens immediately, store secrets as encrypted environment variables, enable team SSO and two-factor authentication, and review the audit log.
planetscale/api/organizations
PlanetScale Organizations API
Risk: A compromised PlanetScale service token or OAuth token allows listing and managing databases, branches, and connection credentials across the organization, leading to data exfiltration or destructive branch operations.
Fix: Create PlanetScale service tokens scoped to a single database with minimal accesses, store them in a secrets manager, and rotate tokens immediately if they appear in build output or repositories.
proc/self/environ
Linux process-environment pseudo-file, a classic local-file-inclusion and SSRF target
Risk: On a successful local file inclusion or path traversal, this leaks the process environment including DB passwords, API keys, and session secrets, and is a classic vector for environ-based code execution.
Fix: Validate and canonicalize all file paths, disable inclusion of user-controlled paths, run with allow_url_include off, and apply least-privilege file permissions to block traversal.
railway/api/projects
Railway Projects API
Risk: A leaked Railway API token exposing projects lets an attacker read service configurations and environment variables (database URLs, secrets) and deploy or delete services, leading to data access and infrastructure takeover.
Fix: Keep Railway tokens out of source control and CI logs, rotate any exposed token, use project-scoped tokens with least privilege, and enable two-factor authentication on the account.
render/api/v1/services
Render Services API
Risk: A valid Render API key reaching the services endpoint lets an attacker list services, read environment variables and secret files, and trigger deploys or modify start commands to run arbitrary code in the hosted environment.
Fix: Store the Render API key as a secret and rotate it if exposed, restrict its use to trusted CI runners, mark sensitive config as secret env vars/files, and enable account 2FA and audit review.
supabase/rest/v1/auth/users
Supabase Auth Users API
Risk: Reaching the auth users table, especially with a leaked `service_role` key, exposes every user record and bypasses Row Level Security, allowing arbitrary reads/writes and full account compromise.
Fix: Keep the `service_role` key strictly server-side, enable and test Row Level Security on every table, and serve clients only the anon key with policies that scope access to the authenticated user.
user-data
Cloud-init user-data path that can contain bootstrap scripts and secrets
Risk: Cloud-init user-data frequently contains bootstrap scripts with embedded secrets, SSH keys, or credentials; retrieval (e.g., via SSRF to the metadata endpoint) hands an attacker instance provisioning details.
Fix: Avoid embedding secrets in user-data, enforce IMDSv2 to block SSRF-based metadata access, and never expose cloud-init artifacts through the web server.
vercel/api/v1/deployments
Vercel Deployments API
Risk: A leaked Vercel token exposing deployments lets an attacker list and inspect builds, read environment variables (often holding API keys and DB URLs), and push malicious deployments to production domains.
Fix: Scope Vercel access tokens to specific teams/projects, rotate any token committed to a repo, mark sensitive env vars as encrypted/Sensitive, and enable deployment protection and audit logging.