| R1 |
High |
Rate limiting not applied |
Dependency exists in package.json but is never imported or used. Consequence: Auth endpoints lack protection against brute-force attacks and automated login attempts. Attackers can test password combinations without restriction, creating direct risk of account takeover. |
| R2 |
High |
Eager loading in services |
The service layer loads all entities + relations for each object. Consequence: For large datasets (10,000+ records) this results in 3-5 second load times. Users experience a "sluggish" interface, leading to frustration. High server load times can cause timeouts during peak traffic. |
| R3 |
High |
Personal data logged in plaintext |
Sensitive user data (email, IP addresses, usernames) written directly to application logs without masking. Consequence: Violates GDPR Articles 5 and 32 regarding data minimization and security measures. In case of log leakage, personal data is exposed. |
| R4 |
High |
No backup verification |
Daily PostgreSQL dumps run via cron but have never been tested through restore. No automated verification that the backup is complete or consistent. Consequence: In case of data loss (corrupt disk, failed migration) there is no guarantee that recovery works. Potentially total loss of order and customer data. |
| R5 |
High |
CTO single point of failure |
All infrastructure, deploy processes, and architecture decisions rest on one person. No documentation of system architecture or operational procedures. Consequence: If CTO becomes unavailable, the team lacks ability to debug production, perform releases, or handle incidents. Critical key-person risk directly affecting business continuity. |
| R6 |
Moderate |
Stripe API keys without rotation |
The same Stripe secret key has been used since project inception (18+ months). The key is hardcoded in environment configuration rather than managed in a secrets manager. Consequence: A compromised key gives full access to payment flows. Without rotation, the exposure window increases in case of leakage. |
| R7 |
Moderate |
12% test coverage |
Only 12% of the codebase is covered by automated tests. Existing tests focus on helper functions, not business logic such as route optimization or price calculation. Consequence: Refactoring and new features risk regressions that are not caught before deploy. Increases cost and time for each release cycle. |
| R8 |
Moderate |
Manual deploy via SSH |
Releases are done through manual SSH to production server, git pull, and pm2 restart. No CI/CD pipeline, no automated tests during deploy. Consequence: Risk of human error during deploy, no rollback mechanism, and lack of audit trail. Downtime from failed releases requires manual debugging. |
| R9 |
Moderate |
WebSocket without authentication |
Real-time updates for delivery tracking sent via WebSocket without token validation on connection. Anyone who knows the endpoint can listen to events. Consequence: Unauthorized parties can follow delivery positions in real time. Potential privacy issue for restaurants and customers. |
| R10 |
Moderate |
No monitoring/alerting |
The application lacks centralized logging, APM, and alerting. Errors are only discovered when customers report problems. No visibility into response times, error rates, or resource usage. Consequence: Outages can persist for hours without the team being notified. Impossible to proactively identify performance issues or capacity needs. |
| R11 |
Moderate |
N+1 queries in order listing |
The order overview generates a separate database query per order to fetch restaurant and driver details. With 500 active orders, this results in 1,500+ queries per page load. Consequence: Response times of 3-8 seconds during lunch peaks. Database load creating bottlenecks for the entire system. |
| R12 |
Moderate |
Docker images not pinned |
Dockerfiles use :latest tags for base images (node:latest, nginx:latest). No lockfiles for exact versions. Consequence: Builds are non-reproducible. An upstream update can break the build or introduce incompatibilities without warning. |
| R13 |
Moderate |
No staging environment |
All changes are deployed directly to production. No separate staging or QA environment for verification before release. Consequence: Bugs and regressions are only discovered in production by end users. Combined with lack of CI/CD, the risk of outages increases significantly. |
| R14 |
Low |
Outdated README |
The project's README describes an older architecture and lacks current installation instructions, environment variables, and API documentation. Consequence: New developers need extensive onboarding with direct guidance from CTO. Reinforces the single-point-of-failure issue (R5). |
| R15 |
Low |
No code standard |
The project lacks ESLint configuration, Prettier, and defined code conventions. Inconsistent naming and formatting in the codebase. Consequence: Code review takes longer and focuses on style instead of logic. Increases technical debt over time and complicates onboarding. |
| R16 |
Low |
Bundle size 2.1 MB |
The frontend bundle is 2.1 MB (gzipped 680 KB) due to unused libraries, non-tree-shaken dependencies, and embedded map images. Consequence: Load time on 3G connection exceeds 4 seconds. Primarily affects drivers in the field with limited connectivity. |
| R17 |
Low |
No a11y audit |
No accessibility audit has been conducted. Contrast, keyboard navigation, and screen reader support are not verified. Consequence: Risk of not meeting the EU Accessibility Directive (2025). Limits potential customer base and may entail legal exposure in public procurement. |