Knowledge Base: Web Application Security & The OWASP Top 10

Overview

Web Application Security is the process of protecting websites, applications, and APIs from external threats. In the context of 2025, this discipline has moved beyond simple input sanitisation. It now encompasses the protection of microservices, the defense of Large Language Model (LLM) integrations, and strict adherence to Australian regulatory frameworks such as the Security of Critical Infrastructure (SOCI) Act and the reformed Privacy Act.

This Knowledge Base entry serves as the central hub for understanding the current threat landscape, specifically through the lens of the OWASP Top 10 and modern Red Teaming methodologies.

The Australian Regulatory Context (2025)

Before addressing technical vectors, it is critical to understand the compliance layer governing web application security in Australia.

• The Privacy Act Reforms: The introduction of a statutory tort for serious invasions of privacy means that a technical vulnerability leading to data exposure (e.g., IDOR) now carries significantly higher legal and financial liability.

• SOCI Act Risk Management Program (RMP): For entities deemed "Critical Infrastructure," web assets are considered critical vectors. Vulnerability management is no longer optional; it is a federal requirement to maintain a "material risk" register.

The OWASP Top 10: 2025 Technical Analysis

The Open Web Application Security Project (OWASP) Top 10 remains the standard awareness document for developers. However, in 2025, the execution of these attacks has evolved.

Below is an analysis of the critical categories. Select a vulnerability for a detailed technical deep-dive.

1. Broken Access Control (A01)

Severity: Critical Trend: Increasing due to API proliferation.

Access control enforces policy such that users cannot act outside of their intended permissions. Failures lead to unauthorized information disclosure or data modification.

• The 2025 Vector (BOLA): Modern applications rely heavily on APIs. Attackers frequently exploit Broken Object Level Authorization (BOLA). This occurs when an API endpoint allows a user to manipulate the ID of an object (e.g., user_id=123 changed to user_id=124) in a GET/POST request without backend validation of ownership.

• Mitigation: Implement mandatory access control checks in business logic, not just the presentation layer. Use unguessable IDs (UUIDs/GUIDs).

2. Cryptographic Failures (A02)

Severity: High Trend: Shifts toward Quantum-Resistant standards.

Previously known as "Sensitive Data Exposure," this category focuses on failures related to cryptography (or lack thereof).

• The 2025 Vector: With the maturity of "Harvest Now, Decrypt Later" attacks, using deprecated protocols (TLS 1.1/1.2 with weak cipher suites) is a significant risk. Furthermore, hardcoded keys in CI/CD pipelines remain a primary entry point for Red Teams.

• Mitigation: Enforce TLS 1.3 for all data in transit. utilize Key Management Systems (KMS) rather than environment variables for secrets.

3. Injection (A03) & LLM Vulnerabilities

Severity: Critical Trend: Evolving rapidly with AI integration.

Injection occurs when untrusted data is sent to an interpreter as part of a command or query.

• The 2025 Vector (Prompt Injection): The newest and most volatile addition to this category. If your web application integrates an LLM (e.g., a customer service chatbot), it is susceptible to Prompt Injection. Attackers use crafted natural language inputs to override the system instructions, forcing the AI to leak backend data or perform unauthorized actions.

• Legacy Vector: SQL Injection (SQLi) remains prevalent in legacy Australian enterprise systems.

• Mitigation: Parameterized queries for SQL. For AI, implement strict output validation and "human-in-the-loop" verification for sensitive actions.

4. Insecure Design (A04)

Severity: High Trend: Focus on "Secure by Design" principles.

This category addresses risks related to design flaws and architectural structures. It differentiates between a "bug" (implementation error) and a "flaw" (design error).

• The 2025 Vector: Business Logic Flaws. Automated scanners cannot detect that a workflow allows a user to apply a discount code ten times in rapid succession. This requires architectural threat modeling during the design phase.

• Mitigation: Implement Threat Modeling (STRIDE) during the SDLC planning phase.

5. Security Misconfiguration (A05)

Severity: Medium/High Trend: Cloud-native misconfigurations.

• The 2025 Vector: With the dominance of cloud-native apps, this frequently manifests as misconfigured S3 buckets, overly permissive CORS (Cross-Origin Resource Sharing) policies, or default credentials left on container orchestration tools (Kubernetes dashboards).

• Mitigation: Infrastructure as Code (IaC) scanning and automated configuration drift detection.

6. Insecure Design (A06)

Severity: High Context: The "Secure by Design" Mandate.

This category covers risks that cannot be fixed by "patching" code because the flaw is in the workflow itself.

• The 2025 Vector: We frequently see this in "Password Recovery" flows. An application might be coded perfectly, but if the design allows a user to reset a password by answering "What is your mother's maiden name?" (information easily found on Australian social media), the design is insecure.

• Mitigation: Move from "DevOps" to "DevSecOps." Security architects must review wireframes before a single line of code is written.

7. Identification and Authentication Failures (A07)

Severity: Critical Context: Credential Stuffing & MFA Fatigue.

Previously known as "Broken Authentication," this covers how the system verifies the user's identity.

• The 2025 Vector: MFA Fatigue (Push Bombing). Attackers script the generation of hundreds of MFA push notifications to an employee's phone at 3:00 AM. The exhausted employee eventually hits "Approve" just to silence the phone.

• Mitigation: Implement "Number Matching" for MFA (the user must type a code displayed on the screen, not just hit 'Approve') and rate-limit authentication attempts aggressively.

8. Software and Data Integrity Failures (A08)

Severity: High Context: CI/CD Pipeline Security.

This category focuses on code and infrastructure that does not protect against integrity violations. This is often where Supply Chain Attacks technically execute.

• The 2025 Vector: SolarWinds-style Pipeline Injection. If your CI/CD pipeline (e.g., Jenkins, GitHub Actions) automatically pulls a library from a public repository without verifying the digital signature, an attacker can inject malicious code into your build process. You deploy a "clean" app that was infected before it even left the compiler.

• Mitigation: Use Code Signing for all artifacts. Implement a "Binary Authorization" policy that prevents unverified containers from launching in your Kubernetes clusters.

9. Security Logging and Monitoring Failures (A09)

Severity: Medium (High Legal Risk) Context: Australian Clinical Labs Precedent.

• The 2025 Vector: The technical risk is that you cannot detect an active breach. The legal risk is now definitive. In the 2025 AIC v ACL case, the court found that retaining firewall logs for only short periods constituted a failure to take "reasonable steps" to protect data.

• Mitigation:

  • Centralise: Logs must leave the web server immediately and go to a read-only SIEM (Security Information and Event Management) system.

  • Retention: Ensure log retention policies match the new Privacy Act recommendations (often 12+ months for critical metadata).

10. Mishandling of Exceptional Conditions (A10) [NEW for 2025]

Severity: Medium Context: API Resilience.

A new addition for 2025, this category highlights what happens when things go wrong.

• The 2025 Vector: Verbose Error Messages. When an attacker sends a malformed payload to your API, does it crash silently, or does it return a stack trace that reveals your database version, internal IP addresses, and framework details? Attackers use these "exceptional conditions" to map your internal network.

• Mitigation: Configure global exception handlers that catch all crashes and return a generic 500 Internal Server Error to the user, while logging the specific stack trace internally for developers.

Advanced Testing Methodologies

To validate defenses against the vulnerabilities listed above, Australian organisations must move beyond compliance scanning.

The Necessity of Logic Testing

Automated tools operate on pattern matching (Input -> Output). They fail to understand context. A human Red Teamer understands that skipping step 3 in a 4-step onboarding wizard creates a user account with elevated privileges—a "Logic Flaw" that no CVE database lists.

Remediation & Next Steps

Securing a web application is an iterative process. The immediate action items for technical teams are:

1. Audit: Review your current application against the specific KB articles linked above.

2. SBOM: Generate a Software Bill of Materials to identify vulnerable components (A06).

3. Test: Schedule a manual penetration test that specifically scopes for Business Logic and API Security, not just automated vulnerability scanning.

Require specific technical guidance?

Our offensive security team specialises in adversarial emulation for high-compliance Australian environments.