hunt-serverless-exposure

Validates serverless functions and API Gateway routes for unauthorized exposure using evidence-gated probes.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-serverless-exposure-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-serverless-exposure
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-serverless-exposure
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-serverless-exposure-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security testers need a disciplined way to verify whether in-scope serverless functions, event sources, and API Gateway routes expose more than authorized capabilities, without triggering write operations, reading environment variables, or producing false positives from scanner noise. ## Core Features & Use Cases - Evidence-Gated Validation: Enforces a fixed baseline → single-variable probe → post-baseline → oracle → evidence workflow so every finding is backed by cloud audit logs or server-side confirmation. - Strict Safety Boundaries: Stops immediately on management API invocation, IAM changes, function updates, async event delivery, third-party data, or irreversible side effects. - False-Positive Filtering: Treats 404s, cloud headers, WAF blocks, and scanner hits as INCONCLUSIVE, and routes cloud-permission findings to hunt-cloud-misconfig and signature issues to hunt-webhook-signature. - Use Case: During an authorized assessment, confirm whether an anonymous or low-privilege identity can reach your own Lambda function route or canary data that should be restricted, with audit-log proof. ## Quick Start Use $hunt-serverless-exposure to plan an evidence-gated, authorized validation of whether my in-scope serverless routes expose unauthorized capabilities.

Frequently Asked Questions about hunt-serverless-exposure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test serverless functions for unauthorized exposure?

Compare anonymous and low-privilege identity access against health endpoints, schemas, errors, and canary data in your own test account using no-op routes. A finding is valid only when cloud audit logs or server-side logs confirm the unauthorized access.

What counts as a real serverless exposure finding versus a false positive?

A valid finding requires an anonymous or low-privilege identity accessing a function, route, or canary that should not be exposed, confirmed by audit evidence. 404 responses, cloud headers, WAF blocks, and scanner hits are all inconclusive.

Can this approach invoke management APIs or read environment variables?

No. The workflow explicitly stops before invoking management APIs, reading environment variables, modifying IAM, updating functions, or delivering asynchronous events. It only plans validation and never grants target operation permissions.

When should serverless testing stop during an assessment?

Stop immediately upon encountering third-party data, shared infrastructure, irreversible side effects, or any step requiring write operations. Cloud permission issues route to cloud misconfiguration review and signature issues to webhook signature analysis.

Does a domain or header match prove function ownership?

No. Domain names and headers do not establish function ownership. Discovery must confirm cloud and function ownership, public routes, HTTP methods, authentication, event triggers, versions, aliases, and logging before any probe.