According to IBM's 2025 Cost of a Data Breach Report, the average cost of a data breach reached $4.88 million — with web application attacks as the most common initial attack vector. Understanding how the major attack types work — and how to defend against them — is no longer optional for any business with an online presence. This guide covers VAPT, the full OWASP Top 10, DDoS, SQL injection, and brute force: what each is, how it works, and the specific countermeasures that stop it.

What is VAPT?

VAPT stands for Vulnerability Assessment and Penetration Testing. The two components are complementary but distinct:

  • Vulnerability Assessment (VA): Uses automated scanning tools (e.g. Nessus, OpenVAS, Burp Suite) to systematically identify and catalog known weaknesses — misconfigurations, outdated software, missing patches, exposed services. VA gives breadth: a complete inventory of potential issues, ranked by severity.
  • Penetration Testing (PT): A manual, ethical hacking exercise in which a security professional actually attempts to exploit discovered vulnerabilities to determine how far a real attacker could go — what data they could access, what systems they could compromise, what the blast radius would be. PT gives depth: validated, real-world risk rather than theoretical.

VAPT combines both into a single engagement. A typical VAPT follows five phases: Reconnaissance (passive information gathering), Scanning & Enumeration (active probing of the target's attack surface), Exploitation (attempting to breach identified weaknesses), Post-exploitation (assessing impact and lateral movement), and Reporting (a written report with severity ratings, evidence, and remediation guidance).

VAPT should be performed annually at minimum, after any major infrastructure change, and before launching a new product or feature that handles sensitive data.

OWASP Top 10 — 2021 (current)

The Open Web Application Security Project (OWASP) publishes the definitive list of the most critical web application security risks. The 2021 edition remains the reference standard in 2026.

A01: Broken Access Control

The #1 risk — and the most widespread. Broken access control means users can act outside their intended permissions: viewing other users' data, accessing admin functions, or modifying records they don't own. Examples: a user changing the userId=123 parameter in a URL to userId=124 and seeing another user's account (Insecure Direct Object Reference, or IDOR); a non-admin user accessing /admin because the route isn't server-side protected. Fix: enforce access control on the server side on every request — never rely on hiding URLs or client-side checks alone.

A02: Cryptographic Failures

Sensitive data exposed due to weak or absent encryption. Common failures: passwords stored as MD5 or SHA-1 hashes (not salted bcrypt/Argon2); data transmitted over HTTP instead of HTTPS; TLS 1.0/1.1 still enabled; encryption keys hardcoded in source code; sensitive data returned in API responses that isn't needed client-side. Fix: enforce HTTPS everywhere with HSTS, use bcrypt or Argon2 for passwords, rotate secrets via environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault), disable deprecated cipher suites.

A03: Injection

Injection flaws — SQL, NoSQL, OS command, LDAP — occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most common form (covered in detail below). OS command injection allows attackers to execute shell commands by injecting into shell-calling functions. Fix: parameterized queries for all database calls, avoid system shell calls that include user input, validate and sanitize all inputs.

A04: Insecure Design

Security flaws that exist at the design stage, not just the implementation. Examples: a password reset flow that relies on security questions (guessable), a rate-limiting policy that doesn't exist at all. Fix: threat modeling during design, not after; security requirements alongside functional requirements.

A05: Security Misconfiguration

The most commonly seen issue in practice: default credentials left enabled, unnecessary services running, verbose error messages that expose stack traces and database schemas, missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security). Fix: automated configuration scanning in CI/CD, disable or remove every default account and service not in use, set all security headers.

A06: Vulnerable and Outdated Components

Using libraries, frameworks, or server software with known CVEs. A single vulnerable npm package, outdated WordPress plugin, or unpatched server can expose the entire application. Fix: automated dependency scanning (Snyk, Dependabot, npm audit), signed releases with verified checksums, remove unused dependencies.

A07: Identification and Authentication Failures

Broken authentication: session tokens that don't expire, session IDs exposed in URLs, passwords without complexity requirements, missing multi-factor authentication on privileged accounts. Fix: short-lived session tokens rotated after login, secure HttpOnly cookies, enforce MFA on all admin accounts, never expose session IDs in URLs.

A08: Software and Data Integrity Failures

Trusting data or code from external sources without verification. Examples: CI/CD pipelines that pull code from unverified sources, insecure deserialization (e.g. a pickled Python object from user input that executes code on load). Fix: verify integrity of all third-party software (hash/signature checking), use integrity attributes on CDN scripts (<script integrity="sha384-...">), sign CI/CD artifacts.

A09: Security Logging and Monitoring Failures

The average time to detect a breach remains over 200 days — largely because security logs are absent, unchecked, or unactionable. Without logging, an attack can succeed and persist undetected for months. Fix: log all authentication events (success, failure, lockout), all access control failures, all inputs that trigger server-side validation errors; ship logs to a centralized SIEM; configure alerts for anomalous patterns.

A10: Server-Side Request Forgery (SSRF)

SSRF allows an attacker to induce the server to make HTTP requests to an unintended location — including internal services that aren't publicly reachable (metadata APIs like AWS's 169.254.169.254, internal databases, Redis instances). Fix: validate and allowlist the URLs and IP ranges your application is permitted to call, disable redirects in server-side HTTP clients, block requests to private IP ranges.

DDoS attacks

A Distributed Denial of Service (DDoS) attack overwhelms a target by flooding it with traffic from thousands or millions of compromised machines (a botnet), making it unable to serve legitimate users.

Three types of DDoS

  • Volumetric attacks — flood raw bandwidth. UDP floods and ICMP (ping) floods send massive volumes of packets, saturating the target's network pipe. Measured in Gbps. Modern attacks can exceed 1 Tbps.
  • Protocol attacks — exploit weaknesses in network protocols. SYN floods send a flood of TCP SYN packets that the server acknowledges but never complete, exhausting the server's connection state table. Ping of Death sends malformed packets that crash or freeze older systems.
  • Application-layer attacks (L7) — mimic legitimate HTTP traffic to exhaust server resources. An HTTP flood sends millions of GET or POST requests. Slowloris keeps many HTTP connections open simultaneously by sending partial headers slowly, preventing the server from closing them — a small botnet can bring down an unprotected web server.

DDoS mitigation

  • CDN-based DDoS protection (Cloudflare, AWS Shield): Absorbs volumetric attacks by distributing traffic across a global anycast network — Cloudflare's network capacity alone exceeds 200 Tbps. The most cost-effective starting point for any site.
  • Web Application Firewall (WAF): Filters application-layer attacks by inspecting HTTP traffic against rule sets. Blocks known bot signatures, enforces rate limits per IP/user agent, and challenges suspicious traffic with CAPTCHA.
  • Rate limiting: Caps requests per IP, per endpoint, per time window at the server or CDN level. Essential for login endpoints and API endpoints.
  • IP reputation & allowlisting: Block known malicious IP ranges; allow only expected geographic regions if your audience is location-specific.

SQL injection

SQL injection (SQLi) is the most exploited injection vulnerability and has appeared in every OWASP Top 10 since its inception. It occurs when user-supplied input is concatenated directly into a SQL query string, allowing an attacker to alter the query's logic.

How it works

Consider a login query built by string concatenation:

SELECT * FROM users WHERE username = '$input_user' AND password = '$input_pass'

If the attacker enters ' OR '1'='1' -- as the username, the query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' -- ' AND password = ''

The -- comments out the rest of the query. The condition '1'='1' is always true, so the query returns the first user in the database — typically the admin account. The attacker is logged in without knowing any credentials.

More damaging variants include UNION-based injection (extracting data from other tables), Blind SQLi (inferring data from true/false responses when the app shows no error output), and Time-based Blind SQLi (using database sleep functions to infer data character by character).

SQL injection prevention

  • Parameterized queries / prepared statements — the definitive fix. The database receives the SQL template and the user input separately; it is impossible for the input to change the query's structure.
  • ORM (Object-Relational Mapping) frameworks — Django ORM, Hibernate, Prisma, Eloquent. When used correctly, they generate parameterized queries automatically.
  • Input validation & allowlisting — validate that inputs conform to expected types and formats (numeric IDs must be integers, email fields must match email regex). Reject, don't sanitize.
  • Least-privilege database user — the application's database account should have only SELECT/INSERT/UPDATE/DELETE on the tables it needs. Never connect as root or sa.
  • WAF — a WAF with SQLi rules catches common patterns and provides a safety net, but is not a substitute for parameterized queries.

Brute force attacks

Brute force attacks attempt to gain unauthorized access by systematically trying credentials until one works. They target login forms, API keys, SSH endpoints, and password reset codes.

Types of brute force attacks

  • Simple brute force: Tries every possible combination of characters. Effective only against very short passwords or PINs.
  • Dictionary attack: Uses a wordlist of common passwords (rockyou.txt has 14 million entries). Highly effective against weak passwords.
  • Credential stuffing: Uses username/password pairs leaked from other data breaches. Since people reuse passwords across sites, a breach at one service enables attacks on many others. Credential stuffing is automated and runs at scale; it's responsible for the majority of "account takeover" incidents.
  • Password spraying: Tries a small number of commonly-used passwords (e.g. "Password1!", "Summer2026") against a large number of accounts. Designed to avoid account lockout policies triggered by many failures on one account.
  • Rainbow table attack: Uses precomputed hash-to-password tables to reverse unsalted password hashes instantly. Defeated by properly salting password hashes.

Brute force prevention

  • Multi-Factor Authentication (MFA): Even if credentials are compromised, a second factor (TOTP app, hardware key, SMS) blocks access. MFA prevents credential stuffing entirely. Enforce MFA on all admin and privileged accounts unconditionally.
  • Rate limiting on authentication endpoints: Limit login attempts to 5–10 per minute per IP. Slow down, challenge, or block after repeated failures.
  • Account lockout with alerting: Lock an account temporarily after N failed attempts (5–10 is typical). Alert the account owner by email so they know an attack occurred.
  • CAPTCHA / bot challenges: Add a CAPTCHA after 3–5 failed login attempts. Google reCAPTCHA v3 or Cloudflare Turnstile challenge bots invisibly and serve a visible puzzle only to suspicious traffic.
  • Bcrypt or Argon2 password hashing: Computationally expensive hashing algorithms make offline brute force against a leaked database take years instead of days. Never use MD5, SHA-1, or unsalted SHA-256 for passwords.
  • Breached password detection: Check new and changed passwords against the Have I Been Pwned Passwords API (k-anonymity model) to reject credentials already known to attackers.
  • Anomaly detection: Flag and investigate logins from new countries, devices, or IP reputation-flagged addresses. Notify users of suspicious activity.

Security hardening checklist

  • Enforce HTTPS across all pages with HSTS headers
  • Run automated VAPT at least annually and after major releases
  • Address all OWASP Top 10 categories in your security review
  • Use parameterized queries or an ORM for all database calls
  • Enable WAF (Cloudflare WAF or AWS WAF) with OWASP core rule set
  • Deploy CDN-based DDoS protection (Cloudflare free tier at minimum)
  • Rate-limit all authentication and password-reset endpoints
  • Enforce MFA on all admin, developer, and privileged accounts
  • Hash passwords with bcrypt (work factor ≥12) or Argon2id
  • Scan dependencies weekly for CVEs (Snyk, Dependabot, npm audit)
  • Set all HTTP security headers (CSP, X-Frame-Options, HSTS, Referrer-Policy)
  • Keep server OS, database, and runtime patched within 30 days of CVE publication
  • Centralize and monitor security logs; alert on auth failures and access control errors
  • Principle of least privilege: each service, user, and API key has only the permissions it needs
  • Run a penetration test before launching any new feature that handles sensitive data

Frequently asked questions

What is VAPT in cybersecurity?

VAPT stands for Vulnerability Assessment and Penetration Testing. Vulnerability Assessment uses automated scanning tools to identify and catalog known weaknesses. Penetration Testing is a manual, ethical hacking exercise that actually attempts to exploit those weaknesses to validate real-world risk. VAPT combines both: VA gives breadth, PT gives depth.

What is the OWASP Top 10?

The OWASP Top 10 is the definitive list of the ten most critical web application security risks, published by the Open Web Application Security Project. The 2021 edition (the most current as of 2026) is led by Broken Access Control (A01), followed by Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Data Integrity Failures, Logging Failures, and SSRF.

How often should we do security testing?

At minimum: a full VAPT annually, automated dependency scanning continuously in CI/CD, and a penetration test before any major release or infrastructure change that handles customer data. Organizations subject to compliance frameworks (PCI-DSS, ISO 27001, SOC 2) typically require quarterly vulnerability scans and annual penetration tests as a baseline.

Is a WAF enough to protect against SQL injection?

No. A WAF provides a useful additional layer of defense and can block many common SQLi patterns, but it is not a substitute for fixing the root cause. Sophisticated attackers can often bypass WAF rules using encoding, fragmentation, or unusual but valid SQL syntax. The correct fix is parameterized queries in the application code — the WAF is the backstop, not the solution.

Want a VAPT or security hardening audit for your web application? Contact iZenTech Solutions for a scoped security review proposal.