Firecrawl Qa Skill Security Audit

The Skill requires an API key for hosted Firecrawl requests, permits asking about credentials for protected flows, and calls for browser and scraping functions. However, the visible text does not say that login credentials are sent to Firecrawl, where the browser runs, how session data is handled, or whether scraped content leaves the user's environment. Third-party processing is possible, but the claimed data flow is not established. A user can ask for execution, logging, and retention details and restrict testing to non-sensitive test accounts.

The Skill says to proceed immediately when the URL is clear, then discover pages and perform browser interactions and form tests. The visible instructions do not first verify site ownership or testing permission, nor define path scope, request rate, or excluded areas. If the user lacks authority over the target, this could cause unauthorized automated access or interaction, although the text does not prove any target is unauthorized. Users can require authorization confirmation, explicit allowed paths and rate limits, and exclusions for admin, payment, and account-changing flows.

This is an active testing instruction, not merely an example or warning: the Skill directs browser-based form interaction and includes “Happy Path” as a form-testing task. On a production site, completing a normal flow could create orders, messages, bookings, or account changes. The visible instructions provide no read-only boundary, staging requirement, or confirmation before consequential submission. This supports a plausible risk, not proof that an action occurred. Users can require a sandbox/test account and prohibit consequential final submissions.