Centinela
A multi-tenant SaaS web security scanner in development: the foundations exist today; scanning is planned.
Role: Product design and development
- Next.js
- FastAPI
- PostgreSQL
- Redis
Problem
Scanning a website for vulnerabilities is useful, but doing it on someone else’s site without permission is a serious problem. Many tools leave that responsibility to whoever uses them and check nothing. For a product meant to be offered as a service to several organizations, that is not enough.
Centinela starts from one idea: only what the user can prove belongs to them gets scanned, and no organization can see another one’s data. Almost the whole design comes from those two rules, which is why I built them before the scanner.
What is planned
Centinela is a product in development. This section separates clearly what already exists from what is still a plan, because I don’t want it to sound more advanced than it is.
What already exists
The foundations are built and tested:
- A database with row-level security that isolates each organization’s data.
- Identity, organizations and teams, with owner, admin, member and viewer roles that the server enforces.
- An interface in Spanish and English, and the structure for different plans, with no billing yet.
- The authorization agreement the user must accept, recording when and which version was accepted.
- Domain ownership verification through a DNS TXT record or a signed and reviewed letter.
This is what can be used today. There is no scanning of any kind yet.
What comes next
The next stages, in order, are the ones that will turn the project into a real scanner:
- A safe outbound path to the internet, so scans can only reach authorized destinations.
- Queues and workers that run scans outside the web application.
- Passive checks of what a site already exposes: headers, TLS, cookies and mail configuration.
- A dashboard with the results and clear, actionable reports.
- Later on, API scanning and non-destructive active checks.
The screens shown in this case are sketches with sample data of what is intended to be built, and their captions say so.
How I approach it
I chose an unglamorous order on purpose. A dashboard with charts can be built at any time, but isolation between organizations and proof of authorization are hard to add once there is data and there are users. Doing them first gives me a base on which the scanner can grow without hidden risks.
Every stage is planned before writing code and closed only when it is tested. I would rather show a small, honest product, with what already works in view and what is missing pointed out, than a long list of promises.
Architecture
Simplified diagram; internal details omitted for privacy.
- The dashboard and the API already exist; every query goes through row-level security in PostgreSQL.
- Before any scan, the domain is verified with a DNS TXT record or a signed letter.
- The queue with workers and the reports are planned and not built yet.
Technical decisions
PostgreSQL row-level security on top of the application's filters.
- Why
- In a product with several organizations, one forgotten filter in a query is enough to show another organization's data. With the rule set in the database, every query stays limited to its own organization even if the code fails.
- Trade-off
- Tests and migrations are more laborious, and every connection has to be careful to state which organization it belongs to.
Verify domain ownership with a DNS TXT record or a signed letter before scanning.
- Why
- Scanning someone else's site without permission is a legal and ethical problem. Asking for proof that only the owner can give leaves a record of the authorization.
- Trade-off
- It adds friction on first use: the user has to touch their DNS or wait for a manual review of the letter.
Tiered access: a limited public snapshot, with the rest behind an authorization agreement.
- Why
- A tier without authorization shows value using only what any visitor can already observe, while the more invasive tiers require an accepted agreement.
- Trade-off
- I have to define carefully where the public part ends and keep what each tier does clear, which complicates the product design.
Gallery
My role
I design and build it on my own. I started with what is hardest to fix later, isolation between organizations and authorization to scan, and left the scanning itself for later. So today it has solid foundations but does not scan anything yet.