By neeshant
Understanding how a web platform works under the hood—and more importantly, how to secure it—is crucial for any developer. Today, we are breaking down the architecture of the TraceX Console. This post will explain how data is retrieved, how a security bypass occurred, the associated risks, and the exact steps to secure the website against future attacks.
*(Note: All sensitive tokens, URLs, and database connection strings have been partially masked to maintain system security while keeping the technical layout realistic.)*
## 1. The Architectural Layout
The system is divided into four main components that communicate with each other:
* **Frontend Screen (TUI):** Hosted on [https://tracexnumber.web.app/](https://tracexnumber.web.app/), this is the main interface where users execute searches and interact with identity caches. It features decoupled, lightweight styling using a high-performance terminal emulator theme that runs entirely client-side without heavy frameworks. Because it is a public domain, it acts purely as a security boundary to collect inputs, display results, and verify session tokens without holding any backend credentials.
* **Backend Proxy:** To protect secret tokens, the frontend converts search queries into relative HTTP calls (like /api/proxy/lookup). The backend proxy receives these calls, acting as a middleman that hides secret API keys from the browser.
* **Cache Database:** This local database saves results the first time a query (like an Aadhaar or phone number) is searched. Subsequent searches load instantly from here (under 150 milliseconds), saving expensive calls to external APIs.
* **API Gateway:** If a search isn't in the Cache database, the proxy asks this external provider gateway to fetch the new details.
### Domain & Routing Structure
Here is how the system organizes its tasks across different URLs to keep things organized:
* **tracexnumber.web.app:** The main website URL where users open the screen and type their search queries.
* **tracex***.onrender.com:** The external provider gateway that fetches live Aadhaar and PAN data.
* **noop***.supabase.co:** The direct SQL database where search results are saved for fast cache lookups.
## 2. Uncovering the Security Hole
### The Broken Object Level Authorization (BOLA) Bypass
The website suffered from a critical security vulnerability called Broken Object Level Authorization (BOLA), meaning the server trusted the client browser too much. Here is exactly how attackers bypassed the credit system:
* Normally, the website screen checks for user credits before showing results.
* However, hackers used tools to capture raw search requests traveling over the internet, completely bypassing the website screen.
* Using a request replayer tool, they changed the Aadhaar number in the raw request body and sent it directly to the server.
* Because the backend server failed to check the user's token for credits in the database before running the search, it successfully fetched and returned PAN details for free.
### Understanding Request Interception
Think of a search query as a physical letter sent through the post office:
* **The Browser (Postman):** Your browser writes, signs, and sends the request to the server.
* **The Interceptor:** Intercepting software acts as a proxy, catching the request in the middle of its journey before it reaches the server.
* **The Tampering:** The hacker uses a request replayer to erase the original query, write a new one, and forward it to the server, making the server think it came directly from the legitimate screen.
* **Why Frontend Limits Fail:** Since the hacker bypasses the frontend entirely, any browser-memory credit checks are completely useless; the server *must* perform these checks itself.
## 3. Critical Security Risks
### Leaked Database Credentials
The project communicates directly with the database using connection keys. If keys for noop***.supabase.co leak, the consequences are critical:
* **Direct Table Manipulation:** Attackers could run SQL commands to read, modify, or delete the entire database, stealing cached vehicle logs, identity files, and user phone records.
* **Altering User Accounts:** Attackers could give themselves infinite free search credits or create fake admin accounts.
* **The Fix:** Always enable Row Level Security (RLS) in the database console. RLS ensures users can only read their own data, blocking attackers from downloading other citizens' records even if keys leak.
### Token Security & Log Leakage
Authentication tokens identify users and grant permissions. Managing them safely is critical to preventing unauthorized system takeovers:
* **refresh_token (The Biggest Threat):** This is a long-lived token (e.g., ref_tok_***) used to automatically generate new access tokens. If stolen, an attacker gains permanent account access and can execute searches indefinitely until the session is manually revoked. It must never be shared or logged.
* **access_token (JWT):** A short-lived credential (e.g., eyJhbGc***) passed in HTTP headers to verify identity on every lookup. While it expires after 1 hour, a stolen active token allows attackers to read, query, and modify user metadata during that window.
### Response Headers & Information Leakage
Poorly configured metadata headers can leak valuable clues to hackers:
* **Wildcard CORS Header (Access-Control-Allow-Origin: *):** This tells browsers that any website on the internet is authorized to send cross-origin requests to your API. In production, it must be restricted to [https://tracexnumber.web.app](https://tracexnumber.web.app) to prevent unauthorized sites from invoking search routines.
* **Server Technology Banners:** Headers like X-Render-Origin-Server: uvicorn and Server: cloudflare reveal your exact backend technologies, allowing hackers to target specific vulnerabilities designed for those versions.
### Admin API Superpowers
Administrative keys (like TX-------***-ADMIN) are super-user keys that bypass all database security limits:
* An attacker with this key can view, download, or edit the search logs, phone numbers, and profile details of all users at once.
* They can control user credits directly (e.g., boosting balances), block active accounts, or create new profiles.
* They can wipe the server database cache, forcing the backend to reload data from external providers and depleting API limits.
* **The Fix:** Admin keys must never be put in browser code or client files; they must remain strictly hidden behind server environment configurations.
## 4. Securing the System: Action Plan
If tokens are leaked or exposed in system logs, you must take immediate action:
* **Clean Console Logs:** Delete all debug statements like console.log(session) that write tokens directly to server logs.
* **Filter Logs:** Configure tracking tools to automatically sanitize and delete access_token and refresh_token properties from payload logs.
* **Session Revocation:** Force affected users to change passwords and manually terminate active sessions in the database to instantly invalidate leaked tokens.
### Three Simple Rules for Website Protection
1. **Enforce Server-Side Credit Checks:** The backend server must check the database to confirm the user's credit balance before showing any data, blocking the request if credits are 0.
2. **Strict CORS Limits:** Configure the proxy server to reject any requests that do not originate directly from your main domain ([https://tracexnumber.web.app](https://tracexnumber.web.app)).
3. **Hide Credentials:** Never write API keys directly in code files; save them in a hidden environment file (.env).
### Developer Security Checklist
Review this simple checklist with your developer to ensure the site is hardened:
* [ ] **Credit Check:** Is the server checking the user's credit balance in the database before calling the API gateway?
* [ ] **CORS Whitelist:** Has the developer blocked all origins except [https://tracexnumber.web.app](https://tracexnumber.web.app) on the proxy backend server?
* [ ] **Environment Secrets:** Are all tokens removed from code files and stored in server Environment Variables?
* [ ] **Database RLS:** Is Row Level Security enabled in the database console for all tables?
* [ ] **Rate Limiting:** Is there a rate-limiting filter configured on the backend server to block IP addresses sending more than 5 requests per minute?
### Simple Code Implementation (For Coders)
Here is a Node.js Express code block to implement CORS restrictions, rate limiting, and credit validation:
```javascript
// 1. Restrict API to your website domain only (CORS)[span_61](start_span)[span_61](end_span)
const corsOptions = {
origin: 'https://tracexnumber.web.app'
};
app.use(cors(corsOptions)); //[span_62](start_span)[span_62](end_span)
// 2. Limit requests (Rate Limiter: max 5 requests per minute)[span_63](start_span)[span_63](end_span)
const limiter = rateLimit({
windowMs: 60 * 1000,
max: 5,
message: { error: 'Too many requests!' }
});
app.use('/api/proxy/*', limiter); //[span_64](start_span)[span_64](end_span)
// 3. Verify user credits in the database before search[span_65](start_span)[span_65](end_span)
async function checkCredits(req, res, next) {
const userId = req.user.id;
const { data } = await supabase.from('users').select('credits').eq('id', userId).single();
if (!data || data.credits < 1) {
return res.status(402).json({ error: 'No credits left!' });
}
// Deduct 1 credit and proceed[span_66](start_span)[span_66](end_span)
await supabase.from('users').update({ credits: data.credits - 1 }).eq('id', userId);
next();
} //
```