Common Vulnerabilities & OWASP Top 10

Vulnerability Mechanism:

User can modify URL or request parameters to access data they shouldn’t. Missing verification of user permissions on server-side.

Prevention Checklist:

• Enforce access control on every request, never trust client-side checks
• Deny by default unless explicitly allowed
• Implement least privilege—users get only required permissions
• Use framework access control mechanisms (Spring Security, ASP.NET Authorization) rather than custom code
• Log and monitor access control failures

Vulnerability Mechanism:

Data transmitted in plain HTTP, stored with weak encryption or no encryption, or keys hardcoded in source code.

Prevention Checklist:

• Encrypt all data in transit (TLS 1.3 everywhere, HSTS), at rest (AES-256 full-disk or database encryption)
• Never store sensitive data you don’t need (PCI-DSS: don’t store CVV, SSN only if absolutely necessary)
• Use strong, up-to-date algorithms (AES-256, RSA-3072+, SHA-256+)
• Protect encryption keys in secure storage (HSM, cloud KMS, not source code)
• Disable caching of sensitive pages

Vulnerability Mechanism:

User input concatenated directly into SQL query, shell command, or LDAP filter. Attacker provides crafted input that changes query meaning.

Prevention Checklist:

• Use parameterized queries (prepared statements) for all database access—never string concatenation
• Stored procedures with bind variables (not dynamic SQL)
• ORM frameworks (Hibernate, Entity Framework) protect against SQLi
• Input validation (deny lists for dangerous characters, but not primary defense)
• Least privilege DB accounts—application user shouldn’t have DROP permission
• ESC (Exploit Sanitization Columns) or RASP (Runtime Application Self-Protection)

Vulnerability Mechanism:

System lacks fundamental security controls from design phase. No threat modeling. Requirements don’t include security.

Prevention Checklist:

• Threat modeling during design phase (STRIDE, PASTA)
• Secure design patterns and principles (defense in depth, least privilege, fail secure)
• Security requirements in user stories (“As a user, I want my password encrypted”)
• Architecture reviews with security focus
• Secure coding standards and peer design reviews

Vulnerability Mechanism:

Dev or test configurations deployed to production. Default passwords unchanged. Debug mode enabled. Directory listing allowed.

Prevention Checklist:

• Immutable infrastructure (images pre-hardened, not configured post-deploy)
• Automated configuration scanning (CIS Benchmarks, cloud security posture tools)
• Remove/replace default accounts and passwords
• Disable directory listing, verbose error messages in production
• Infrastructure as Code (IaC) with security baked into templates (Terraform, CloudFormation)
• Regular automated scanning (Qualys, Nessus) and compliance audits

Vulnerability Mechanism:

Application includes outdated dependency (Log4j 2.x, older jQuery with XSS, unpatched OS). Attackers exploit public CVE.

Prevention Checklist:

• Software Composition Analysis (SCA) tools: Snyk, Dependabot, OWASP Dependency-Check
• Monitoring CVE feeds (NVD, vendor advisories) for dependencies
• Remove unused dependencies—smaller attack surface
• Regular patch cycles—security updates applied within SLA (typically 30 days for critical)
• Virtual patching (WAF rule) when immediate patch unavailable
• SBOM (Software Bill of Materials) inventory—know exactly what's in your software

Vulnerability Mechanism:

Weak password policy (123456 allowed), no rate limiting on login, predictable session tokens, credential stuffing attacks succeed.

Prevention Checklist:

• MFA mandatory—blocks 99.9% of automated credential attacks
• Rate limiting / account lockout after N failed attempts (with care to avoid DoS)
• Check passwords against HaveIBeenPwned API when setting new password
• Secure session management: regenerate ID on login, HttpOnly cookies, short timeout
• Enforce password policy: 8+ chars, complexity, no common passwords
• CAPTCHAs to slow down automated attacks

Vulnerability Mechanism:

Attacker modifies code or dependencies in transit or at rest. No integrity checks. Deserialization of untrusted data executes code.

Prevention Checklist:

• Code signing with hardware security modules (HSM)—private key never leaves hardware
• Reproducible builds—verify binary matches source
• SBOM (Software Bill of Materials) for transparency
• Verify digital signatures of all dependencies and updates
• Secure CI/CD pipelines (isolated runners, signed commits, PR approval)
• Never deserialize untrusted data (use JSON, not binary serialization)

Vulnerability Mechanism:

No logging of authentication attempts. Logs not centralized. No alerts for suspicious activity. Logs stored locally (attacker deletes).

Prevention Checklist:

• Centralized logging (SIEM: Splunk, Elasticsearch, Sentinel)
• Log all authentication attempts (success/failure), access control failures, input validation failures
• Audit trail includes sufficient context: user, timestamp, IP, user agent, action, resource
• Real-time alerts and monitoring for critical events (multiple failed logins, privilege escalation)
• Integrate with SOAR for automated response
• Protect logs from tampering (write-once storage, centralized collection)

Vulnerability Mechanism:

Web app fetches URL provided by user (for screenshot, import, metadata). Attacker provides internal IP (169.254.169.254 AWS metadata). Server fetches internal resource, returns to attacker.

Prevention Checklist:

• Network segmentation: application servers shouldn’t access sensitive services (metadata, internal APIs)
• URL allowlisting for outbound requests
• Disable HTTP redirections in server-side requests
• Validate and sanitize all user-provided URLs
• Cloud metadata service access only via IAM policies, not from application instances