标签：#netlify

While doing a routine hardening pass on an internal Firebase panel — codename PanelControl , a management tool used daily by multiple operators with different roles — what was supposed to be "let's add a few Telegram alerts for suspicious activity" turned into discovering that the app's entire login system was just a UI filter. Anyone who opened the site already had, automatically, a Firebase identity with full read/write access to the database. Here's what happened, and how it got fixed in 5 phases without ever locking the team out mid-shift. The setup PanelControl is a vanilla-JS internal panel backed by Firebase Realtime Database + Firestore. Operators log in with email/password, checked client-side against a database node, with a lockout after failed attempts. Nothing unusual so far. The original ask was narrow: add Telegram notifications for a handful of suspicious events — brute-force attempts, a never-before-seen device for an operator, an unauthorized attempt to reach the Admin section, DevTools opened during use. Pure alerting work. Bug #1: the login button that always unlocks Before writing any alerting logic, a review of the existing Admin-area password check turned up this: // ❌ The "|| true" makes the whole condition always truthy function checkAdminPwd () { if ( el . value || true ) { unlockAdmin (); // runs regardless of what's typed, or nothing at all } } A debug leftover that made it to production. Anyone who landed on the Admin password overlay got in by clicking "Log in" — password or not. Fixed by actually wiring the real permission check, plus a server-side-verified fallback in case the function were ever called directly from the console. The real discovery: a shared, hardcoded Firebase credential Looking at the Realtime Database Rules ahead of the alerting work surfaced something much bigger. The Rules restricted read/write to a single fixed auth.uid — reasonable, until you check who actually gets that uid . This ran unconditionally, for every

A client wanted to know who was on their site and on which page, the way Tidio's widget showed them — but without paying for a Tidio subscription, on an external WordPress site that doesn't use Firebase. The result: an external tracker hooked to an independent Firebase project, live presence via onDisconnect , persistent history in Firestore with IP geolocation — and a final debugging session where a browser CORS error was masking a server crash caused by an empty string instead of null . The context The client already had a third-party live-chat script installed on their site, and that's where the idea came from: "can we see who's on the site and on which page, without using that service?" Two constraints made the request less trivial than usual: the site hadn't been migrated to my usual stack yet — it was still running on WordPress, on different hosting — and there was no intention of introducing Firebase on the WordPress side. Step 1 — understanding what a live-chat widget actually does Before building anything, it was worth looking at what the already-installed script actually did. The tag pasted into the site was just a small loader: it creates a hidden iframe, loads the widget's real "brain" inside it from the provider's servers, which then connects via websocket to their backend to stream presence, current page and events in real time. The interesting part — "see who's on the site and on which page" — isn't in the public script: it all lives server-side at the provider, behind authentication, a proprietary dashboard and a subscription. There was nothing to "detach" from that service: it's client code tied to someone else's backend by design. But the pattern itself — a script tag hooking into an external backend — is exactly what's needed to build the same feature independently, and it fits well with Firebase, which has a native presence mechanism built for precisely this. Step 2 — live presence with Firebase Realtime Database Firebase Realtime Database has a