Real Estate Agency · 2025
Selva Habitat
A secure, modern real-estate platform, built, launched, and kept running with bank-grade login security.
Overview
A premium property-listings website for the Catalan real-estate market, built from the ground up: a fast public site for buyers, and a secure back office for the agency's own team to manage everything themselves. It runs on modern cloud infrastructure that updates itself automatically, safely, every time we ship an improvement.
The problem
A real-estate agency needs two very different things from one website: an inviting public site where buyers can browse listings and get in touch, and a locked-down back office where staff can safely manage listings, agents, and leads. That back office is the higher-value target for attackers, since it can publish public listings and holds sensitive client contact details.
The solution
We built a fast public site where visitors can browse listings and submit inquiries, valuation requests, or newsletter sign-ups. On the staff side, we built a complete back office to manage every property, agent, office, and lead in one place, protected by a password plus a one-time security code sent by email, so a leaked password alone can't get an attacker in. Staff can also upload photos and manage site content directly, with no developer help needed.
Architecture
Three Kubernetes deployments (backend, frontend, admin) behind an Ingress that splits the public domain from a separate admin subdomain, with the backend on a ReadWriteOnce volume for uploads.
Technologies
Backend
Frontend
Admin
Infrastructure
Engineering challenges
Preventing username enumeration and brute force on admin login
Login compares against a dummy bcrypt hash when the username doesn't exist, so failed attempts take the same time whether or not the account is real. Lockouts are keyed both per-IP-and-username and per-username-across-IPs, closing the gap a single-key lockout leaves open to distributed brute force.
Trusting X-Forwarded-For only from known proxies
Client IP for rate-limiting is only read from forwarded headers if the direct connecting peer is in an explicit trusted-proxy allowlist; otherwise a spoofed header could be used to bypass IP-based rate limits entirely.
Recreate deployment strategy for a volume-backed backend
The backend Deployment explicitly uses Recreate instead of the Kubernetes default RollingUpdate, because it mounts a ReadWriteOnce uploads volume, and a rolling update would deadlock trying to attach the same volume to two pods at once.
Results
- →New updates go live automatically and safely, with no manual deployment steps and no downtime.
- →Two-factor login security and built-in protection against automated attacks close the two most common ways a site like this gets compromised.
- →Every inquiry, contact requests, valuation requests, newsletter sign-ups, lands in one place instead of being scattered across separate inboxes, so nothing gets missed.
Want something like this?