# firepwn: testing Firebase security rules the way a real client does

> firepwn is a local web tool for checking the security rules of a Firebase project, and its distinguishing choice is to drive the real Firebase client SDK rather than the REST API, so that authorisation behaviour matches what an application would actually see. It covers authentication, Firestore, Storage and callable Functions, and it ships an automated collection scanner that is read-only by default.

**0xbigshaq/firepwn-tool** — Firepwn is a tool made for testing the Security Rules of a firebase application. 

- Repository: https://github.com/0xbigshaq/firepwn-tool
- Stars: 675 · Forks: 43
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/0xbigshaq-firepwn-tool

## The client SDK, not the REST endpoints

The choice that defines this tool is stated in the second line of the README. Most Firebase testing scripts rely on the REST API, the documented HTTP interface for the database, while firepwn uses the actual Firebase client SDK to test both authentication and authorisation across multiple Google services. That difference is not cosmetic. The SDK is what a real application uses, so requests travel the same path, with the same headers, the same auth token handling and the same rule evaluation entry points that the application would hit. A test made against the REST API can tell you whether a rule denies a read, but it cannot tell you whether the SDK would send the request in a way the rule permits, which is where misconfigured rules often hide. The audience is anyone authorised to assess a Firebase project, typically a developer checking their own rules before launch, or a security reviewer working with permission. The tool runs locally in your browser, so the test traffic originates from your machine against the project you configure.

## Bootstrapping a target from its firebaseConfig

The first step is pointing the tool at a project. You enter the firebaseConfig values, which are apiKey, authDomain, databaseURL, projectId and storageBucket. The configuration panel accepts these either as individual form fields or as a raw JSON or JavaScript config object pasted in, which is the practical route since a web app usually embeds the config object in its bundle and you can copy it from there. Once the values are in, you click Start and the Firebase SDKs are bootstrapped, and the rest of the interface stays locked until that initialisation succeeds. That gating is deliberate. Everything after initialisation, the auth panel, the Firestore queries, the Storage operations, the function invocations, depends on a working client, so the tool refuses to let you operate on a half-configured session. The output panel logs every operation with success, error and info indicators as it happens, which matters when you are stepping through a sequence of rule checks and want to see exactly which call was rejected.

## Four ways to arrive as a user

Authorisation testing is only interesting if you can be several different users, and the auth panel gives you four paths. Email and password lets you sign in with existing credentials or register a new account, which is the common case and the one that exercises rules keyed on a user id. Google OAuth works by pasting an oauthIdToken captured from the target application's sign-in flow, for instance from browser developer tools, to assume a Google session without running the sign-in flow yourself. Multi-factor authentication over SMS lets you complete the verification challenge with the code you receive, which covers projects that require a second factor. Anonymous sign-in lets you test the rules that allow unauthenticated or anonymous users, and that is a category worth checking on its own, because a permissive rule that assumes a signed-in user is a common source of exposed data. The four methods together let you compare what a rule returns for a signed-in user, for an anonymous user, and for a user with a different identity.

## Firestore, Storage and callable Functions

The data operations cover a wide surface. On Firestore there is full CRUD. Get supports a document limit, a sort order and query filters, with the operators ==, <, <=, >, >=, array-contains and in, so you can test a rule that restricts a range or a membership rather than only a whole-collection read. Set creates documents or overwrites existing ones, with an optional merge mode, Update modifies specific fields in existing documents, and Delete removes documents. Nested collections and subcollections are supported, which matters because rules are often written for the top level and forgotten below it. Cloud Storage operations cover listing files and directories, uploading and downloading files, deleting files, and fetching metadata for stored objects. Cloud Functions can be invoked, specifically callable functions, with custom parameters, which is how you test authorisation on backend logic rather than on data. The scope across the three services is what makes the tool a rule assessment tool rather than a database viewer.

## Autopwn probes common collection names

The automated feature is called Autopwn, and it discovers and tests Firestore collections. Collection discovery probes more than 120 common collection names, users, orders, settings and similar, to find readable data. You can add your own collection names to the scan, with an option to scan only the custom names instead of the built-in list. Write and delete testing is available but disabled by default, explicitly to avoid accidental damage, which is the right default for a tool that runs destructive checks against a live database. Concurrency is configurable, from a gentle setting of 5 parallel probes to an aggressive 50. Results appear live in a progress bar with per-collection read, write and delete permission badges, so the output is a matrix of what is allowed rather than a list of failures. The trade-off is obvious and worth stating: a scanner that probes by name is a blunt instrument, and a collection with an unusual name is invisible to it unless you add it yourself.

## Custom scripting straight from the console

Because the Firebase services are attached to window globals during initialisation, you can drop out of the interface and run your own queries from the browser console against the live services. The globals are window.authService for the Auth service, window.firestoreService for Firestore, window.functionsService for Functions and window.storageService for Storage. That is the escape hatch for anything the panels do not cover, and it is also the reason the tool is a development environment rather than a script. You are not limited to the operations the interface exposes, you can drive the SDK yourself with the same session the tool set up. The limitation follows from the same design. The globals exist only in the page where the tool was initialised, so a console session depends on that state, and anything you run by hand bypasses the output panel, so it will not be logged the way the panel operations are.

## A local Next.js app, and how the versions line up

Running the tool is two commands. The dependencies are installed with npm, and the development server is started with the dev script, after which you open the local address the README names:

```bash
npm install
npm run dev
```

The repository is a Next.js application, with the scripts block in the manifest covering the development server, the production build, the start command, and the lint and format tasks handled by Biome:

```json
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "biome check .",
```

The dependency list is a typical modern React stack, with Next 16.1.6, React 19, the Radix UI component primitives, Tailwind, lucide-react for icons and form tooling built on radix and hookform resolvers. The interface itself is built from shadcn style components, with components.json, tailwind.config.ts and a styles directory. Note the version story in the manifest, where the version field reads 1.1.0 while the newest GitHub release is v1.2.0 from 2026-03-01, following v1.1.0 and v1.0.0 on the same day in February, so a checkout of main is ahead of what the manifest suggests. The licence is GPL-3.0, which is worth noting for a tool that connects to live projects, and the last push to main was on 2026-04-26.

## Conclusion

firepwn suits a developer or security reviewer with authorisation to test a Firebase project who wants to check that the rules behave as intended across authentication states, and who prefers driving the actual client SDK to poking at the REST endpoints. It is the wrong tool for a project that only needs a linter for its rules file, and it is not a substitute for testing with a real app, since the SDK path and the application path can still differ. Before using the Autopwn scanner, set the concurrency low and leave write and delete testing disabled, and confirm with the project owner that the target belongs to you, because the read probes alone can pull real user records into the output panel.

## FAQ

### How do I run firepwn locally?

Install the dependencies with npm install and start the development server with npm run dev, then open the local address the README lists. The interface is a Next.js application served from your own machine.

### What does the Autopwn feature do, and is it destructive by default?

It probes more than 120 common Firestore collection names to find readable data, and it can also test write and delete access on discovered collections. The write and delete testing is disabled by default to avoid accidental damage, and concurrency is configurable from 5 to 50 parallel probes.

### Which Firebase services can firepwn test?

Firestore with full CRUD, query filters and subcollections, Cloud Storage for listing, uploading, downloading, deleting and metadata, callable Cloud Functions with custom parameters, and four authentication paths, which are email and password, Google OAuth, SMS multi-factor and anonymous sign-in.

### How is firepwn different from a REST API based Firebase testing script?

The README states that most Firebase pentest scripts rely on the REST API, while firepwn uses the actual Firebase client SDK, so that both authentication and authorisation are exercised the way an application would exercise them.

## Sources

- [0xbigshaq/firepwn-tool on GitHub](https://github.com/0xbigshaq/firepwn-tool)
- [Issues](https://github.com/0xbigshaq/firepwn-tool/issues)
- [License: GPL-3.0](https://github.com/0xbigshaq/firepwn-tool/blob/main/LICENSE)
- [README](https://github.com/0xbigshaq/firepwn-tool/blob/main/README.md)
- [Releases](https://github.com/0xbigshaq/firepwn-tool/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xbigshaq-firepwn-tool