June 24, 2026
So… what does OIIAI have to do with cybersecurity?
Recently, while exploring a web game on browser (https://oiiai.cat/games), I came across a curious UI behavior:

By Allen Rodger
1 min read
the score ranking was displaying a rendering error ([object Object]). That small frontend "leak" sparked my curiosity: what would happen if I tried to interact directly with the API behind that interface?
What followed was not an intrusion, but a very instructive black-box security audit about how modern applications are protected.
1. The Starting Point
While inspecting network requests, I identified the /api/scores endpoint. With a console open, I wrote a simple script to simulate score submissions, trying to understand how the backend validated incoming data.
2. Testing the Defenses (Vector by Vector)
The intention was not to cause harm, but to understand the system's boundaries:
SQL Injection (SQLi): I attempted to inject SQL commands (' OR 1=1 --) into the playerName field. The result? The system treated the input as plain text. It became clear that the backend uses prepared statements, making database injection attacks ineffective.
Cross-Site Scripting (XSS): I tested several payloads, such as <script>alert(1)</script> and <svg/onload=...> tags. The system, however, proved resilient, likely due to a strict Content Security Policy (CSP) blocking unauthorized script execution, combined with input sanitization.
Endpoint Enumeration: I attempted to access common administrative routes (/admin, /config). All returned 404, confirming that the system has a minimal attack surface.
3. The "Key Insight": The Stack Trace
The most revealing moment occurred when I intentionally sent malformed JSON. The server responded with a detailed error:
SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at parse (/app/node_modules/body-parser/lib/types/json.js:92:19)
...SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at parse (/app/node_modules/body-parser/lib/types/json.js:92:19)
...This stack trace was a "treasure": it revealed that the application runs inside a Docker container (/app) and uses the Express framework. While informative for me, this exposed detail is an important reminder for developers about masking errors in production environments.
4. Conclusion and Lessons Learned
After running the tests, the conclusion was clear: the application has a robust defensive infrastructure. The combination of Cloudflare, restrictive CSP, prepared statements, and input sanitization makes the system highly secure.
The frontend visual bug I found is just a reminder that even in well-protected backend systems, user experience can still be impacted by implementation details in the interface.
What I learned:
- The importance of proper error handling to avoid leaking environment information.
- How good server configuration (CSP + Docker) mitigates basic risks.
- The value of understanding why a defense works, not just looking for failures.