Lesson 8: Application Security — OWASP Top 10 Vulnerabilities

What You Will Learn in This Lesson

• What the OWASP Top 10 is and why it matters for every organization running web applications
• How each of the Top 10 vulnerability categories works, with real-world attack scenarios
• Practical defenses and secure coding practices to mitigate each vulnerability
• How OWASP Top 10 maps to SAMA CSCC and NCA ECC requirements for application security

Why Application Security Cannot Be an Afterthought

How many web applications does your organization expose to the internet? If you run online banking, a customer portal, a payment gateway, or even an internal HR system — each one is a potential entry point for attackers. Unlike network-layer attacks that firewalls can catch, application-layer attacks slip through port 443 looking exactly like legitimate traffic. Your WAF helps, but it cannot save you from flawed business logic or broken authentication buried deep in your code.

The Open Web Application Security Project (OWASP) maintains a periodically updated list of the ten most critical web application security risks. The current version — OWASP Top 10:2021 — is built from real-world breach data contributed by hundreds of organizations worldwide. Think of it as a prioritized checklist: if your applications are vulnerable to items on this list, attackers will find and exploit them.

The OWASP Top 10:2021 — Category by Category

A01: Broken Access Control

This moved from #5 to #1 in the 2021 edition — and for good reason. Broken access control means users can act outside their intended permissions. A customer viewing another customer's account details, an employee escalating their own role to administrator, or an API endpoint that returns sensitive records without checking authorization — these are all broken access control. In Saudi financial institutions, this vulnerability directly violates SAMA's requirements for data segregation and least-privilege access.

Defense: enforce access control on the server side (never trust the client), deny by default, implement role-based access control (RBAC), and log every access control failure for monitoring.

A02: Cryptographic Failures

Previously called "Sensitive Data Exposure," this category focuses on failures related to cryptography — or lack thereof. Storing passwords in plain text, using deprecated algorithms like MD5 or SHA-1 for hashing, transmitting data over HTTP instead of HTTPS, or hardcoding encryption keys in source code. For organizations handling financial data under SAMA oversight, cryptographic failures can trigger both regulatory penalties and catastrophic data breaches.

Defense: classify your data by sensitivity, encrypt data at rest and in transit using strong algorithms (AES-256, TLS 1.2+), never roll your own cryptography, and rotate keys on a defined schedule.

A03: Injection

SQL injection, NoSQL injection, OS command injection, LDAP injection — whenever user-supplied data is sent to an interpreter without proper validation or sanitization, injection attacks become possible. Despite being one of the oldest vulnerability classes, injection still appears in production applications regularly.

Practical Example: A Saudi bank's internal loan processing system accepts a customer ID parameter in its URL. An attacker modifies the parameter to: 1 OR 1=1; DROP TABLE customers;--. Without parameterized queries, the database executes the malicious SQL, potentially destroying the entire customer table. One missing prepared statement — and years of customer data vanish.

Defense: use parameterized queries (prepared statements) exclusively, validate and sanitize all input, apply the principle of least privilege to database accounts, and use an ORM where appropriate.

A04: Insecure Design

This is new in the 2021 edition and represents a fundamental shift in thinking. Insecure design means the application was architecturally flawed before a single line of code was written. No amount of perfect implementation can fix a broken design. For example, a password recovery flow that relies solely on security questions, or an API that returns full customer records when only a name is needed.

Defense: adopt threat modeling during the design phase (STRIDE or PASTA methodologies), use secure design patterns, establish abuse case stories alongside user stories, and conduct design reviews before development begins.

A05: Security Misconfiguration

Default credentials left unchanged, unnecessary services enabled, verbose error messages exposing stack traces to users, missing security headers, or cloud storage buckets left publicly accessible. Security misconfiguration is the gap between having security features and actually configuring them correctly. It is the most commonly found issue in penetration tests of Saudi financial institutions.

Defense: establish hardening baselines for all platforms, automate configuration checks with tools like CIS Benchmarks, remove all default accounts and unnecessary features, and implement a repeatable hardening process across environments.

A06: Vulnerable and Outdated Components

Your application is only as secure as its weakest dependency. Running an outdated version of Apache Struts led to the Equifax breach affecting 147 million people. Every open-source library, framework, and runtime in your stack is a potential attack vector if not kept current.

Defense: maintain a software bill of materials (SBOM), use tools like OWASP Dependency-Check or Snyk to scan for known vulnerabilities, subscribe to security advisories for your stack, and establish a patching SLA — critical CVEs within 48 hours, high within one week.

A07: Identification and Authentication Failures

Weak password policies, missing multi-factor authentication on critical functions, session tokens that do not expire, credential stuffing attacks against login pages — authentication failures give attackers the keys to your kingdom. For banking applications, this is particularly dangerous because a compromised session means direct access to financial transactions.

Defense: implement MFA on all externally facing authentication, enforce strong password policies with breach-database checks (like HaveIBeenPwned), set proper session timeouts, and use rate limiting on login endpoints.

A08: Software and Data Integrity Failures

This covers scenarios where code and infrastructure lack integrity verification. Using libraries from untrusted sources without checksum verification, CI/CD pipelines without integrity controls, or auto-update mechanisms that do not validate signatures. The SolarWinds supply chain attack is the textbook example — attackers compromised the build pipeline to distribute malicious updates to thousands of organizations.

Defense: verify digital signatures on all software and updates, secure your CI/CD pipeline with signed commits and artifact verification, implement Subresource Integrity (SRI) for CDN-hosted scripts, and review deserialization inputs rigorously.

A09: Security Logging and Monitoring Failures

If you cannot detect an attack, you cannot respond to it. Many organizations log authentication events but ignore authorization failures, API abuse, or data access anomalies. According to industry studies, the average time to detect a breach is still over 200 days. Without proper logging, your incident response plan from Lesson 9 is dead on arrival.

Defense: log all authentication, access control, and input validation failures with sufficient context, send logs to a centralized SIEM (like Splunk, Elastic, or Wazuh), establish alerting rules for suspicious patterns, and test your detection capabilities regularly through red team exercises.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when an application fetches a remote resource based on a user-supplied URL without validation. An attacker can trick the server into making requests to internal services, cloud metadata endpoints (like AWS 169.254.169.254), or other backend systems that are not exposed to the internet. The Capital One breach in 2019 was enabled partly through an SSRF vulnerability that accessed AWS IAM credentials via the metadata service.

Defense: validate and sanitize all user-supplied URLs, use allowlists for permitted domains and IP ranges, disable unnecessary URL schemes (file://, gopher://), and segment network access so application servers cannot reach sensitive internal services.

Putting It Into Practice — A Simple Secure Code Check

Here is a quick example of vulnerable vs. secure code for the most common issue — SQL injection in a Python application:

# VULNERABLE — never do this
query = f"SELECT * FROM accounts WHERE id = '{user_input}'"
cursor.execute(query)

# SECURE — use parameterized queries
query = "SELECT * FROM accounts WHERE id = %s"
cursor.execute(query, (user_input,))

And for Node.js applications using Express, always set security headers:

// Install and use helmet for security headers
const helmet = require('helmet');
app.use(helmet());

// Explicitly set Content-Security-Policy
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'"],
    styleSrc: ["'self'", "'unsafe-inline'"],
    imgSrc: ["'self'", "data:"],
    connectSrc: ["'self'"],
    frameSrc: ["'none'"],
  }
}));

Connecting to the Saudi Regulatory Landscape

Application security is not optional under Saudi regulations — it is explicitly mandated. SAMA's Cyber Security Framework (CSCC) requires financial institutions to implement secure software development lifecycle (SSDLC) practices and conduct regular application security assessments. Domain 5 of the framework specifically addresses application security controls including input validation, output encoding, and session management. The NCA Essential Cybersecurity Controls (ECC 2-2024) similarly require vulnerability management and secure development practices under its Application Security subcategory. Organizations processing payment card data must also comply with PCI-DSS v4.0 Requirement 6, which mandates secure coding practices, code reviews, and protection against the OWASP Top 10. Failing a SAMA assessment on application security controls is one of the most common findings — and one of the most avoidable.

Common Mistakes to Avoid

• Relying solely on a WAF: A Web Application Firewall is a safety net, not a substitute for secure code. WAFs can be bypassed with encoding tricks and logic-based attacks. Always fix vulnerabilities in the source code first, then layer a WAF on top as defense in depth.
• Running vulnerability scans without fixing findings: Many organizations scan their applications regularly to satisfy compliance checkboxes, but remediation backlogs grow unchecked. A scan report sitting in a shared drive is not security — establish SLAs for fixing critical, high, medium, and low findings and track them to closure.
• Ignoring APIs: Modern applications are API-first, but many security programs still focus exclusively on web front-ends. Your REST and GraphQL APIs are equally — if not more — exposed to injection, broken access control, and authentication failures. Test them separately and thoroughly.

Lesson Summary

• The OWASP Top 10:2021 identifies the most critical web application security risks based on real-world data, with Broken Access Control now the number one threat
• Each vulnerability category has specific, actionable defenses — from parameterized queries for injection to threat modeling for insecure design — that should be integrated into your development lifecycle
• Saudi regulations (SAMA CSCC, NCA ECC, PCI-DSS v4.0) explicitly require application security controls that align closely with OWASP Top 10 mitigation practices

Next Lesson

In the next lesson, we will cover: Incident Response — A 6-Step Plan — how to build and execute an effective incident response plan that meets SAMA and NCA requirements, from preparation and detection to containment, eradication, recovery, and lessons learned.

Ready to apply these concepts in your organization? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment and find out how your application security posture measures up.