Securing a Multi-Vendor Marketplace

Prashanth Kumar Nagapaga, Cybsersecurity Architect | Technical Advisor
December 19, 2025

A multi-vendor marketplace is a complex attack surface.

You have customer data, merchant data, delivery partner data, payment information, order history, location tracking, and financial transactions. Each component is a potential vulnerability. Each integration is a potential entry point.

This is the story of how we built security into CenterShops—the cloud architecture, the zero-trust principles, the penetration testing process, and the vulnerabilities we found and fixed.

The Security Challenge

When we started building CenterShops, security was not an afterthought. It was a core requirement.

We knew that:

• A data breach would destroy customer trust
• A payment fraud incident would cost us financially and reputationally
• A service disruption would impact merchants and delivery partners
• Regulatory non-compliance would result in fines or shutdown

We needed to build security into every layer of the platform.

The Cloud Security Architecture We Built

We designed our AWS infrastructure around defense in depth—multiple layers of security controls so that if one layer failed, others would still protect the system.

Layer 1: Network Isolation (VPC and Subnets)

We used AWS Virtual Private Cloud (VPC) to isolate our infrastructure:

Public subnets: Only the load balancer (Nginx) was exposed to the internet. All other services were in private subnets.

Private subnets: Application servers, databases, and internal services had no direct internet access. They could only be reached through the load balancer or VPN.

Database subnet: MySQL RDS instances were in a separate subnet with even more restricted access. Only application servers could connect to the database.

Why: Network segmentation limits the blast radius of a breach. Even if an attacker compromised the load balancer, they could not directly access the database.

Trade-off: More complex network configuration. But the security benefit was essential.

Layer 2: Identity and Access Management (IAM)

We used AWS IAM to control who could access what:

Principle of least privilege: Each service and user had only the permissions they needed. Application servers could read from S3 but not delete. Developers could view logs but not modify production databases.

Role-based access: We used IAM roles instead of hardcoded credentials. Application servers assumed roles to access AWS services. This eliminated the risk of leaked credentials.

MFA for admin access: All admin users required multi-factor authentication (MFA) to access the AWS console or production systems.

Why: Proper IAM configuration prevents unauthorized access and limits the damage from compromised credentials.

Trade-off: Required careful planning and ongoing maintenance. But it was fundamental to security.

Layer 3: Secrets Management (AWS KMS and Secrets Manager)

We never stored secrets (API keys, database passwords, encryption keys) in code or configuration files:

AWS Secrets Manager: All secrets were stored in Secrets Manager and rotated automatically.

AWS KMS (Key Management Service): Encryption keys were managed by KMS. We used KMS to encrypt data at rest (database, S3 files) and in transit (TLS/SSL).

Environment-specific secrets: Development, staging, and production environments had separate secrets. A compromised dev environment could not access production data.

Why: Hardcoded secrets are a common vulnerability. Centralized secrets management reduces this risk.

Trade-off: Added complexity to deployment and configuration. But it eliminated a major security risk.

Layer 4: Web Application Firewall (AWS WAF)

We used AWS WAF to protect against common web attacks:

SQL injection protection: WAF rules blocked requests with SQL injection patterns.

XSS (Cross-Site Scripting) protection: WAF rules blocked requests with XSS payloads.

Rate limiting: WAF rules limited the number of requests from a single IP address to prevent brute force attacks.

Geo-blocking: We blocked traffic from countries where we did not operate, reducing the attack surface.

Why: WAF provides an additional layer of defense against common web vulnerabilities.

Trade-off: False positives occasionally blocked legitimate traffic. We tuned WAF rules based on logs and feedback.

Layer 5: DDoS Protection (AWS Shield)

We used AWS Shield Standard (included with AWS) to protect against Distributed Denial of Service (DDoS) attacks:

Automatic detection: Shield detected and mitigated common DDoS attacks automatically.

CloudFront integration: We used CloudFront CDN to absorb traffic spikes and reduce load on origin servers.

Why: DDoS attacks can take down a platform. Shield provided baseline protection.

Trade-off: Shield Standard is free but has limitations. Shield Advanced (paid) offers more protection, but we did not need it initially.

Layer 6: Logging and Monitoring (CloudWatch and GuardDuty)

We used AWS CloudWatch and GuardDuty to detect and respond to security incidents:

CloudWatch Logs: All application logs, access logs, and error logs were sent to CloudWatch. We set up alerts for suspicious patterns (failed login attempts, unusual API calls).

AWS GuardDuty: GuardDuty analyzed CloudTrail logs, VPC flow logs, and DNS logs to detect threats (compromised instances, unauthorized access, malicious IPs).

Automated alerts: Critical security events triggered alerts to our operations team via Slack and email.

Why: You cannot respond to threats you do not detect. Logging and monitoring are essential for incident response.

Trade-off: Generated a lot of log data, which increased storage costs. But the visibility was worth it.

The Penetration Testing Process

We conducted internal penetration tests quarterly to identify vulnerabilities that automated tools might miss.

Our Penetration Testing Methodology

1. Reconnaissance: We mapped the attack surface (public endpoints, APIs, mobile apps, admin panels).

2. Vulnerability scanning: We used automated tools (OWASP ZAP, Burp Suite) to identify common vulnerabilities.

3. Manual testing: We manually tested for business logic flaws, authentication bypasses, and privilege escalation.

4. Exploitation: We attempted to exploit identified vulnerabilities to understand their impact.

5. Reporting: We documented findings with severity ratings (Critical, High, Medium, Low) and remediation recommendations.

6. Remediation: We fixed vulnerabilities based on severity and re-tested to confirm fixes.

Critical Vulnerabilities We Found and Fixed

Vulnerability 1: OTP Rate Limiting Bypass

Finding: During penetration testing, we discovered that our OTP (One-Time Password) system did not properly enforce rate limits. An attacker could trigger unlimited OTP requests by rotating IP addresses or user agents.

Impact: This could lead to SMS cost abuse (we paid for each OTP sent) or denial of service (overwhelming the SMS gateway).

Solution: We implemented multi-layered rate limiting:

• Per phone number: Max 3 OTPs per hour
• Per IP address: Max 10 OTPs per hour
• Per device fingerprint: Max 5 OTPs per hour
• Added CAPTCHA after 2 failed OTP attempts

Result: OTP abuse attempts dropped to zero. SMS costs remained predictable.

Trade-off: Legitimate users who lost their phone or changed devices occasionally hit rate limits. We added a manual override process for such cases.

Vulnerability 2: Insecure Direct Object Reference (IDOR) in Order API

Finding: The order details API endpoint (/api/orders/{order_id}) did not properly validate that the requesting user owned the order. An attacker could enumerate order IDs and view other users' orders.

Impact: Privacy breach. Attackers could see customer names, addresses, order contents, and payment methods.

Solution: We added authorization checks to verify that the requesting user owned the order or had admin privileges. We also implemented order ID obfuscation (using UUIDs instead of sequential integers).

Result: IDOR vulnerability eliminated. Order data was properly protected.

Trade-off: UUID-based order IDs were longer and less user-friendly. But the security benefit was essential.

Vulnerability 3: Missing API Authentication on Admin Endpoints

Finding: Some admin API endpoints (used for merchant approval, payout processing) were accessible without proper authentication. An attacker with network access could potentially approve fraudulent merchants or payouts.

Impact: Financial fraud. Attackers could approve fake merchants or unauthorized payouts.

Solution: We implemented role-based access control (RBAC) for all admin APIs. Only users with specific roles (admin, finance) could access these endpoints. We also added audit logging for all admin actions.

Result: Admin endpoints were properly secured. All admin actions were logged for accountability.

Trade-off: Required refactoring of admin authentication logic. But it closed a critical security gap.

Vulnerability 4: Weak Session Management

Finding: Session tokens were not properly invalidated after logout. An attacker who obtained a session token (via XSS or network sniffing) could continue using it even after the user logged out.

Impact: Session hijacking. Attackers could impersonate users.

Solution: We implemented proper session invalidation on logout. We also added session expiration (tokens expired after 24 hours of inactivity) and session binding (tokens were tied to IP address and user agent).

Result: Session hijacking risk significantly reduced.

Trade-off: Users had to log in more frequently. But the security benefit was worth it.

Vulnerability 5: Insufficient Input Validation

Finding: Some API endpoints did not properly validate input, allowing injection attacks (SQL injection, command injection, XSS).

Impact: Data breach, code execution, or defacement.

Solution: We implemented strict input validation using Laravel's validation framework. We also used parameterized queries to prevent SQL injection and output encoding to prevent XSS.

Result: Injection vulnerabilities eliminated.

Trade-off: More verbose code (validation logic for every input). But it was essential for security.

The Security Tools We Integrated

We used a combination of tools to maintain security:

SAST (Static Application Security Testing): Semgrep scanned our codebase for vulnerabilities during development.

DAST (Dynamic Application Security Testing): OWASP ZAP tested our running application for vulnerabilities.

SCA (Software Composition Analysis): Snyk scanned our dependencies for known vulnerabilities.

MobSF (Mobile Security Framework): MobSF analyzed our Flutter mobile apps for security issues.

Dependency updates: We used Dependabot to automatically create pull requests for dependency updates.

Impact: These tools helped us catch vulnerabilities early in the development cycle.

Trade-off: Required investment in tooling and CI/CD integration. But it was essential for maintaining security.

The Real Lesson

Security is not a feature you add at the end. It is a discipline you practice throughout the development lifecycle.

Here is what we learned:

Defense in depth: No single security control is sufficient. Use multiple layers (network isolation, IAM, secrets management, WAF, logging) to protect against different attack vectors.

Zero trust: Never trust, always verify. Even internal services should authenticate and authorize requests.

Penetration testing is essential: Automated tools catch common vulnerabilities, but manual testing finds business logic flaws and complex attack chains.

Fix vulnerabilities by severity: Critical and high-severity vulnerabilities should be fixed immediately. Medium and low-severity vulnerabilities can be prioritized based on risk and resources.

Security is ongoing: New vulnerabilities are discovered constantly. Regular security reviews, dependency updates, and penetration testing are essential.

Why This Matters to Employers

This experience demonstrates several critical capabilities:

Cloud Security Architecture: Designing secure infrastructure on AWS using VPC, IAM, KMS, WAF, Shield, and GuardDuty.

Penetration Testing: Conducting systematic security assessments to identify vulnerabilities before attackers do.

Vulnerability Remediation: Prioritizing and fixing security issues based on severity and impact.

Security Automation: Integrating security tools (SAST, DAST, SCA) into CI/CD pipelines for continuous security.

Incident Response: Building logging, monitoring, and alerting systems to detect and respond to security incidents.

Looking Ahead

The lessons from CenterShops security now inform how we approach ChittaTaxis:

• Cloud security architecture from day one (VPC, IAM, KMS, WAF)
• Zero-trust principles for all internal and external APIs
• Automated security testing integrated into CI/CD
• Quarterly penetration testing to identify vulnerabilities
• Incident response plan and regular drills

The core insight: In a marketplace, security is not optional. It is the foundation of trust. Without it, no amount of features, marketing, or operational excellence will save the platform.

Next in this series: When Traction Isn't Enough: PMF, Shutdown, and the Path to ONDC