OWASP Top-10: How We Secure Every Custom Web Application We Build
Security is not a feature you add to a web application after it is built. It is an architectural property that must be present from the first line of code. At Marketing Wise, we apply the OWASP Top-10 framework — the industry standard checklist for web application security vulnerabilities — to every custom web application we deliver from Noida. This article explains what each risk category means in practice and exactly how we address it in our builds.
A01: Broken Access Control
The most common vulnerability in production web applications. Broken access control occurs when users can access data or perform actions they should not be permitted to. Our mitigation: role-based access control (RBAC) implemented at the API layer — not just the UI layer. Every API endpoint validates the requesting user's role and resource ownership before returning data. UI-level hiding of buttons is not access control; it is decoration.
A02: Cryptographic Failures
Sensitive data stored or transmitted without appropriate encryption. Our implementation: all data at rest encrypted with AES-256. All data in transit enforced over TLS 1.2 minimum with HSTS headers. Passwords hashed with bcrypt (cost factor ≥12). API keys and secrets stored in environment variables or AWS Secrets Manager — never in source code or database rows.
A03: Injection (SQL, NoSQL, Command)
Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. Our mitigation: parameterised queries via Prisma ORM or pg library prepared statements for all database operations — no raw string concatenation for SQL. Input validation at the API boundary using Zod or Joi schema validation. Command execution (where required) uses execFile with explicit argument arrays, never shell string interpolation.
A04: Insecure Design
Architectural decisions that create security risks regardless of implementation quality. We address this at the design phase with threat modelling — identifying trust boundaries, attack surfaces and data flows before writing code. Rate limiting, account lockout policies, and audit logging are designed in from the start, not retrofitted.
A05: Security Misconfiguration
Default credentials, unnecessary features enabled, verbose error messages in production, open cloud storage buckets. Our deployment checklist: disable default admin accounts, remove unused endpoints, configure production error handlers to return generic messages (not stack traces), audit S3/GCS bucket ACLs, set security headers (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options) on every response.
A06: Vulnerable and Outdated Components
Third-party libraries with known CVEs. We run npm audit and Snyk scans as part of the CI/CD pipeline — a dependency with a high-severity CVE fails the build. For AMC clients, we perform monthly dependency audits and patch updates as part of the maintenance contract.
A07: Identification and Authentication Failures
Weak password policies, missing multi-factor authentication, insecure session management. Our implementation: JWT access tokens (short-lived, 15 minutes) with refresh token rotation, bcrypt password hashing, account lockout after 5 failed attempts, optional TOTP-based MFA for admin roles, and secure HttpOnly cookie storage for refresh tokens (not localStorage).
A08: Software and Data Integrity Failures
Insecure CI/CD pipelines, unsigned packages, unverified webhook payloads. We verify all incoming webhook payloads (Razorpay HMAC-SHA256, WhatsApp HMAC-SHA1) before processing. CI/CD pipeline steps run in isolated environments with pinned dependency versions. Infrastructure changes require pull request review before deployment.
A09: Security Logging and Monitoring Failures
No audit trail when a breach occurs. Every application we build includes: structured application logging (Winston or Pino) with correlation IDs, authentication event logging (login, logout, failed attempts, password reset), admin action audit trails, AWS CloudWatch or GCP Cloud Logging for infrastructure events, and alerting on anomalous patterns (bulk data export, repeated failed auth).
A10: Server-Side Request Forgery (SSRF)
Attackers trick the server into making requests to internal network resources. Our mitigation: validate and allowlist all URLs before making server-side HTTP requests, block requests to private IP ranges (10.x.x.x, 192.168.x.x, 172.16.x.x, 169.254.x.x), and use metadata service protection on AWS EC2 instances (IMDSv2 required).
Security compliance is a baseline requirement on every Marketing Wise project — not a premium add-on. If you are evaluating a custom web application development partner in Noida or Delhi NCR and want to understand how they handle security, ask them to walk you through their OWASP implementation. Call us at +91-95-602-919-70.