Capabilities

ReserveX Security Public Report

I just did my first security assessment of reservexbd.com. I only performed passive recon, which means I did not run active scans or exploit anything. Below is a clear, student-style bullet summary that contains everything from the public report.

- Overview: 15 security issues found in total; 2 of them are critical.
- RXBD-001 (critical): DNS leaks the real server IP behind Cloudflare. Attackers can bypass Cloudflare protections (firewall, DDoS protection, rate limits) and talk directly to the origin server, which makes all other issues much worse.
- RXBD-002 (critical): The media storage bucket is publicly accessible. File paths are present in the page HTML, so anyone can download stored media such as restaurant photos and possibly user uploads.
- RXBD-003: Open redirect on the login page via the unvalidated ?next= parameter. This can be abused for phishing by sending users to a malicious site after login.
- RXBD-004: Signup OTP has no visible rate limiting. Four or six digit OTPs are brute-forceable without an account lockout or throttling.
- RXBD-005: Login error messages reveal account existence by returning different messages for wrong password versus account not found. This enables phone number enumeration.
- RXBD-006: Missing important security headers such as Content Security Policy (CSP), HSTS, and X-Frame-Options, increasing risk of clickjacking, mixed content, and other attacks.
- RXBD-007: Payment iframe for bKash and Nagad fails to load on restaurant pages. Likely a CSP misconfiguration is blocking the provider, causing users to be unable to pay and resulting in immediate revenue loss until fixed.
- RXBD-008: Potential authorization issue with bookings that use simple numeric IDs (for example, /bookings/1234/). If ownership checks are missing, a logged-in user could view or cancel others' bookings. I could not verify this with authenticated testing, so it remains a possible but common mistake.
- RXBD-009: Contact form lacks CAPTCHA, increasing spam and automated abuse risk.
- RXBD-010: Django admin is exposed at the default /admin/ path and is frequently probed by bots, increasing the attack surface.
- RXBD-011: No robots.txt is present, so search engines may index sensitive paths unintentionally.
- RXBD-012: Email addresses are obfuscated with a trivial XOR scheme in the HTML; this can be decoded in seconds and offers no real protection.
- RXBD-013: No sitemap.xml is provided.
- RXBD-014: Password reset OTP lacks visible rate limiting as well, mirroring RXBD-004 and allowing brute force of reset codes.
- RXBD-015: Registration does not verify email ownership, so someone can sign up with another person's email and cause that person to receive booking notifications without consent.

- Chain risk: These findings can chain together. For example, find the real server IP (RXBD-001), bypass Cloudflare, brute force OTPs (RXBD-004/RXBD-014), take over accounts using enumeration (RXBD-005), and then view or cancel bookings (RXBD-008) or steal deposits. Each step in the chain is supported by findings in the report.
- What worked: HTTPS is active, Cloudflare is configured (but bypassable by RXBD-001), phone OTP is implemented for registration, and payment gateways use authorized providers.
- Report status: I prepared a full sanitized report with CVSS scores, evidence, and remediation steps for all 15 findings. The private report containing exact hostnames and paths was delivered to the ReserveX team. This public version redacts sensitive technical details.

If you do security research or web development, I would appreciate any feedback or suggestions.