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.
View: ReserveX_Security_Report_Public(Google Drive)