E-Commerce App (Flutter)
There is no server to fall back on — when the client talks straight to Firestore, the rules file IS the entire trust boundary.
- Flutter
- Dart
- Firebase
About this project
A Flutter storefront — product catalogue, cart, checkout, order history — backed entirely by Firebase Auth and Cloud Firestore, with no backend server of its own. That architecture is common, convenient, and exactly where the danger lives.
With no server in the middle, every write goes straight from a phone to the database. Whatever validation the app does in Dart is a suggestion an attacker simply skips — they send the HTTP request themselves. That makes firestore.rules the entire trust boundary, not a second layer behind one. This project ships two rulesets and a real demo script that fires identical HTTP requests at both, against a real Firestore emulator: under the naive rules, a Rs 1,499 kettle is bought for one paisa, one user reads and overwrites another's order, a negative quantity produces a negative order total, and an arbitrary unchecked field persists. Under the fixed rules, every one of those is rejected while the legitimate order still goes through — because the fixed rules read the real price off the product document with get(), and restrict every order to exactly the fields the app actually writes.
What you will learn
- Understand why a serverless client app makes firestore.rules the whole trust boundary
- Validate a price server-side by reading the real product document, never the write request's claim
- Write rules that restrict the exact field set a document may contain, not just its values
- Prove a security fix by running the identical requests against both a naive and a fixed ruleset
- Reuse the same "validate against stored truth, not client input" pattern in any BaaS-backed app
Before you start
- Flutter and Dart basics — widgets, state, and async/await
- Flutter SDK 3.x — no paid Firebase project needed, the local emulators do everything
- Node 18+ to run the security-rules demo tooling
Academic integrity notice
These projects are provided for learning, experimentation and reference. Understand the code, modify it for your own requirements, and acknowledge external work according to your institution’s academic policies. Priodemy does not supply work to be submitted as your own.
Features
- Two real rulesets — naive and fixed — and one demo script that runs the identical requests against both
- Five real, reproducible exploits under naive rules: price tampering, cross-user read, cross-user overwrite, negative quantity, arbitrary field injection
- A fixed ruleset that reads the true price from the product document rather than trusting the request
- Field-set restriction with hasOnly() — an order can only contain the fields the app itself writes
- 16 unit tests over the cart and order models, runnable with no Firebase at all
- Runs entirely on the local Firebase emulators — no paid project, no cloud account, no billing
Technology stack
Track: Mobile · Level: Major project
What is included
- A complete Flutter app — catalogue, cart, checkout, order history — commented throughout
- firestore.rules and firestore.rules.naive, plus tool/rules-demo.mjs, the real exploit-vs-fix proof
- A README with both full, unedited emulator transcripts side by side
Delivered as a 64 KB ZIP. SHA-256 published under Changelog so you can verify it.
System requirements
- Operating system
- Any
- Runtime
- Flutter SDK 3.x, Node 18+, Firebase CLI. No paid Firebase project needed.
Licence
Learn from it, change it, and use it in your own coursework and personal projects. Do not resell it or pass it off as your own original work.
- Personal and educational use
- Modifying the code however you like
- Using it as the basis of your own coursework, with honest acknowledgement
- Putting your modified version in a portfolio or on your own GitHub
- Reselling or redistributing the project, modified or not
- Presenting it as your own original work
- Commercial deployment — see the Commercial licence
Support window: 6 months from download.
Frequently asked
Do I need a paid Firebase project to run this?
No. Everything — the app, the auth, the database, and both security-rules demos — runs against the local Firebase emulators, which are free and need no cloud project or billing account. lib/firebase_options.dart ships with obvious placeholder values, not a real key, so you drop in your own when you are ready to deploy.
What exactly does the naive ruleset get wrong?
Five separate things, each proven with a real HTTP request against a real emulator: it lets a client set its own price (a Rs 1,499 item was bought for one paisa), lets any signed-in user read and overwrite any other user's order, accepts a negative quantity producing a negative order total, and accepts arbitrary extra fields the app never writes. The fixed ruleset rejects all five while the legitimate order still succeeds.
Why does this matter more than in an app with a backend?
Because there is no backend to catch it. In a conventional app, the server re-validates whatever the client sends, so a weak client check is a bug with a safety net. Here the client talks straight to Firestore, so the rules file is the only thing standing between a request and the database. That is the one idea this project exists to demonstrate.
Changelog
- First release
SHA-2565bb2e18b9b7f06c621728242f7bde7240f8f9735f193576d24ad391479d11ee9
You might also like
Free To-Do App in Flutter
setState does not update the screen — it marks a subtree dirty, and the difference is the whole model.
- Flutter
- Dart
Free Expense Tracker in Flutter
Dart’s int becomes a JavaScript number on the web — the app tells you which one it is running on.
- Flutter
- Dart
- CustomPainter
Premium Habit Tracker with SQLite
A streak is a claim about consecutive days, and the boundary cases are where every naive counter breaks.
- Flutter
- Dart
- SQLite
Premium Real-Time Chat App
A query filter is a convenience, not a security boundary — nothing stops an attacker sending the unfiltered read instead.
- Flutter
- Dart
- Firebase