MODULE 3: APPLICATION SECURITY

Application Security

is the practice of finding, fixing, and preventing security vulnerabilities at the application layer — across design, code, and runtime — rather than relying solely on network or infrastructure defenses.

Application Security

Covers custom code, open-source components, APIs, and configuration

Application Security

Spans the full lifecycle — not just a pre-release scan

Application Security

Balances developer speed with risk reduction

Confidentiality

Protect sensitive data from unauthorized

access

Integrity

Ensure code and data aren't tampered with

Availability

Keep applications running under attack

OWASP TOP 10

regularly updated industry-standard awareness document that represents a broad consensus on the most critical security risks to web applications.

Open Worldwide Application Security Project

OWASP meaning

OWASP Top 10

A minimum standard for application security programs

OWASP Top 10

A shared vocabulary between developers, testers, and auditors

OWASP Top 10

A prioritization guide — not an exhaustive checklist

Broken access control

Cryptographic Failure

Injection

Insecure Design

Security Misconfiguration

Vulnerable and Outdated Components

Identification and Authentication Failure

Software and Data Integrity Failure

Security logging and monitoring failure

Server side request forgery

OWASP TOP 10

Broken access control

Users can act outside their intended permissions — viewing or modifying data, or invoking functions, that should be restricted.

Broken access control

Enforce access checks server-side, by default deny

Use centralized authorization logic

Log and alert on access-control failures

Cryptographic failure

Sensitive data is exposed due to weak, missing, or misconfigured encryption — in transit or at rest.

Cryptographic failure

Encrypt sensitive data at rest and in transit

Use strong, current algorithms and key management

Avoid storing data that isn't needed

Injection

Untrusted input is sent to an interpreter as part of a command or query, altering execution (e.g., SQL, NoSQL, OS, LDAP injection).

Injection

Use parameterized queries / prepared statements

Validate and sanitize all untrusted input

Apply least-privilege database accounts

Insecure Design

Use threat modeling during design

Apply secure design patterns and reference architectures

Define abuse cases, not just use cases

Insecure Design

Missing or ineffective security controls at the design stage — a flaw no amount of implementation care can fully fix.

Security misconfiguration

Insecure default configurations, incomplete setups, open cloud storage, or verbose error messages expose the application.

Security misconfiguration

Harden and automate secure configuration baselines

Remove unused features, accounts, and sample apps

Keep environments consistent across dev/stage/prod

Vulnerable and outdated components

Using libraries, frameworks, or modules with known vulnerabilities, or components that are unsupported and unpatched.

Vulnerable and outdated components

Maintain an inventory (SBOM) of components

Monitor for and patch known CVEs promptly

Use Software Composition Analysis (SCA) tools

Identification and authentication failure

Enforce multi-factor authentication

Use secure, expiring session tokens

Implement rate limiting and lockouts on login

Identification and authentication failure

Weak session management or authentication allows attackers to compromise passwords, keys, or session tokens.

Software and data integrity failure

Code and infrastructure that don't verify integrity — e.g., unsigned updates, insecure CI/CD pipelines, unsafe deserialization.

Software and data integrity failure

Verify digital signatures for updates and packages

Secure CI/CD pipelines and build integrity

Avoid insecure deserialization of untrusted data

Security logging and monitoring failure

Insufficient logging, detection, and alerting lets breaches go unnoticed — often for months.

Security logging and monitoring failure

Log authentication, access-control, and validation failures

Centralize logs with tamper-evident storage

Establish alerting and incident-response playbooks

Server side request forgery

Validate and allow-list outbound destinations

Segment networks and restrict internal service access

Disable unused URL schemas and redirects

Server side request forgery

An application fetches a remote resource without validating the user-supplied URL, letting attackers reach internal systems.

Secure SDLC

embeds security activities into every phase of software delivery — from planning through maintenance — rather than bolting it on at the end.

shift-left

This ____ approach catches issues earlier, when they're cheaper and faster to fix.

Requirements and planning

Security requirements are defined

alongside functional ones — compliance

needs, data sensitivity, and risk tolerance

are scoped up front.

Requirements and planning

Cheapest phase to fix issues in

Requirements and planning

Define security & compliance requirements

• GDPR, HIPAA, PCI-DSS, or internal policy as applicable

Classify data sensitivity

• Identify what needs the strongest protection

Establish risk acceptance criteria

• Agree on what risk levels require sign-off

Secure Design & Threat Modeling

Teams model how the system could

be attacked before writing code,

choosing architecture and controls

that reduce the attack surface.

Secure Design & Threat Modeling

Threat modeling (e.g., STRIDE)

• Systematically identify spoofing, tampering, and other threats

Select secure design patterns

• Reuse vetted authentication, session, and access-control patterns

Define trust boundaries

• Map where data crosses between components or privilege levels

Secure Development

Developers write code following

secure coding standards, supported

by tooling that catches issues as

they're introduced.

Secure Development

Follow secure coding guidelines

• Input validation, output encoding, safe APIs

Peer code review with security lens

• Catch logic flaws automated tools may miss

Run SAST in the IDE / pre-commit

• Immediate feedback before code is even merged

Testing & Verification

Builds are verified with layered

testing — automated and manual —

before release, combining static,

dynamic, and dependency analysis.

Testing & Verification

Static Application Security Testing

• Analyze source code without executing it

Dynamic Application Security Testing

• Probe the running application for exploitable flaws

Software Composition Analysis & pen testing

• Check dependencies and simulate real attacks

Deployment & Maintenance

Security continues after release —

hardened deployment, continuous

monitoring, and a process for

handling newly discovered issues.

Deployment & Maintenance

Harden production configuration

• Least privilege, secrets management, network segmentation

Continuous monitoring & logging

• Detect anomalies and active exploitation quickly

Patch management & incident response

• A clear path from discovery to fix to disclosure

Static application security testing

WHEN

Early — during development, on source code

HOW

Analyzes code, byte-code, or binaries without running

them

FINDS

Insecure coding patterns, injection flaws, hardcoded

secrets

NEEDS

Access to source co

Dynamic application security testing

WHEN

Later — against a running application

HOW

Sends attacks to the live app, like an external attacker

FINDS

Runtime issues, auth flaws, misconfigurations

NEEDS

A deployed, running instance

SAST

scan source code, bytecode, or binaries “from

the inside” without executing the program — catching

insecure patterns as soon as code is written.

SAST

• Higher false-positive rate

• Can't catch runtime/config issues

• Language- and framework-specific

• Needs source code access

SAST

Finds issues very early (shift-left)

• Pinpoints the exact file and line

• Scales across the entire codebase

• Integrates into IDE and CI pipelines

SonarQube

Checkmarx

Semgrep

Fortify

SAST examples

DAST

probe a running application “from the outside” — sending real requests to uncover exploitable flaws the way an attacker would find them.

DAST

Runs later — needs a deployed build

• Slower than static scans at scale

• Limited code-level detail on root cause

• May miss code paths not exercised

DAST

Tests the app as attackers experience it

• Language- and framework-agnostic

• Catches runtime and config issues

• Low false-positive rate on confirmed findings

OWASP ZAP

Burp Suite

Acunetix

Netsparker

DAST Examples