Web application security focuses on protecting the software that runs in a browser or serves requests over HTTP, including its code, data, sessions and the APIs it exposes. General network security concerns the protection of the underlying infrastructure, such as firewalls, routers and transport paths. The two overlap, but a firewall can allow a legitimate HTTPS request that carries a malicious payload designed to exploit application logic. Web application security therefore examines input handling, authentication, business logic and data flows inside the application itself. Practitioners combine both disciplines, because a well-configured network can still host an application with injection flaws, and a secure application can still be exposed by weak infrastructure.
Every web interaction begins with a client sending an HTTP request containing a method, a URL, headers, cookies and sometimes a body. The server processes that request and returns a response that the browser renders. Because clients fully control everything they send, any value in the request can be altered, including hidden form fields, query parameters, cookies and custom headers. Attackers use tools such as intercepting proxies to modify these values and observe how the server reacts. The core lesson is that the client side is never trustworthy, so the server must validate, authorize and sanitize every element of each request rather than assuming the browser enforced rules correctly.
Injection occurs when untrusted input is interpreted as code or commands by an interpreter, such as a database query engine. It persists because developers often concatenate user input directly into query strings, a pattern that is easy to write and hard to notice during review. The reliable defense is parameterized queries or prepared statements, which keep data separate from query structure. Input validation and output encoding add protection in other contexts, such as HTML or operating system commands. Organizations also use static analysis and code review to flag unsafe string building. In practice, a single unparameterized search field can expose an entire customer table, which is why this category remains prominent in published risk rankings.
Cross-site scripting, or XSS, happens when an application includes attacker-controlled content in a page without proper encoding, so the victim's browser executes it as legitimate script. The script can read session data, alter the page or send requests on the user's behalf. Reflected, stored and DOM-based variants differ in where the malicious input is stored or processed. Defenses include context-aware output encoding, which treats text differently in HTML, attributes and JavaScript, along with validation and a Content Security Policy that restricts which scripts may run. Secure frameworks that escape output by default reduce accidental exposure. A realistic example is a comment field that stores a script and runs it for every visitor who views the thread.
Broken access control allows users to perform actions or view data beyond their intended permissions, such as changing the account number in a URL to read another customer's records. It is damaging because it often requires no technical exploit, only an understanding of how identifiers are exposed. Effective authorization checks the permission of the requesting user for every object and every function on the server, not merely in the user interface. Principles such as deny by default, least privilege and centralized authorization logic reduce gaps. Developers should test each endpoint with users of differing roles. For example, an administrative route hidden from menus but reachable by direct URL is a common and serious failure.
Authentication verifies that a user is who they claim to be, and weaknesses here expose every protected resource. Strong designs store passwords using slow, salted hashing algorithms designed for password storage, rather than fast general hashes. They enforce reasonable length requirements, screen against known breached passwords, and protect login endpoints against brute force through rate limiting and lockout or delay strategies that avoid enabling denial of service. Multi-factor authentication adds a second proof of identity, which blocks many credential-stuffing attacks. Password reset flows deserve equal attention, because a weak reset question or predictable token can bypass the primary login entirely. Standards such as the NIST digital identity guidelines offer widely used recommendations that organizations adapt to their risk profiles.
A session ties a series of HTTP requests to a single authenticated user, usually through a token stored in a cookie. Because HTTP is stateless, this token is effectively the proof of identity for every request, so its protection is critical. Good practice generates session identifiers with a cryptographically secure random generator, transmits them only over encrypted connections, and sets cookie attributes such as Secure, HttpOnly and an appropriate SameSite value. The server should regenerate identifiers after login and expire idle or absolute sessions. Logout must invalidate the server-side session, not merely delete the cookie in the browser. A common realistic failure is a session token that remains valid for weeks after a user changes their password.
Cross-site request forgery tricks an authenticated user's browser into sending a request to a site where they are logged in, so the request carries valid session cookies. The attacker cannot read the response but can cause a state-changing action such as transferring funds or altering account settings. Defenses rely on proving that the request originated from the application itself. Anti-CSRF tokens unique to each session or form are the traditional approach, with the server verifying the token on each state-changing request. The SameSite cookie attribute provides an additional layer by limiting when cookies are sent cross-site. Frameworks often include these protections by default, but developers must avoid disabling them for convenience.
Transport security begins with enforcing HTTPS everywhere, using valid certificates and enabling HTTP Strict Transport Security so browsers refuse plaintext connections after the first secure visit. Security headers add browser-enforced protections. A Content Security Policy restricts the sources of scripts, styles and frames, which limits the damage from injected code. The X-Content-Type-Options header prevents MIME sniffing, while frame-ancestors directives or X-Frame-Options guard against clickjacking. A Referrer-Policy controls how much URL information is shared with other sites. These headers are not substitutes for secure code, but they provide defense in depth. Teams often verify them with automated scanners and periodic manual review after each release.
Input validation checks that data conforms to expected type, length, format and range before the application processes it. Allowlist validation, which accepts only known good patterns, is more reliable than trying to enumerate every malicious input. Validation should happen on the server, since client-side checks are easily bypassed, although client-side checks improve usability. Validation alone does not replace output encoding or parameterized queries, because data that passes validation can still be dangerous in a specific context. Teams should reject unexpected input clearly and log the event rather than silently altering it. For example, a postal code field can enforce a country-specific pattern, but a free-text comment still requires encoding when displayed.
A secure development lifecycle integrates security activities into each phase of building software, rather than testing for flaws only at the end. Threat modeling during design identifies assets, trust boundaries and likely attack paths while changes are still inexpensive. Developers receive secure coding training and use frameworks with safe defaults. Static analysis, software composition analysis and code review run during development, while dynamic testing verifies running behavior. Security requirements, such as authorization rules for each feature, are written alongside functional requirements. The benefit is cumulative: fewer defects escape to production, and fixes cost far less. Many organizations adopt the OWASP Software Assurance Maturity Model to measure and improve these practices over time.
Automated scanners send large numbers of standardized requests to detect known vulnerability patterns, misconfigurations and missing headers. They are fast, repeatable and useful for continuous coverage, but they struggle with complex business logic and often produce false positives that require human triage. Manual penetration testing relies on a skilled tester who understands the application's purpose and chains weaknesses together, such as combining an information disclosure with an access control flaw. Penetration tests are periodic and scoped, while scanners can run on every build. A mature program uses both, scanning continuously and commissioning expert testing before major releases or after significant architectural change. Results from both should feed a tracked remediation process.
Modern web applications assemble large amounts of code from open-source libraries, frameworks and packages, so a vulnerability in one dependency can affect thousands of applications. Risk arises from known flaws, abandoned projects, malicious packages that imitate legitimate names, and compromised build tools. Teams manage this by maintaining an inventory of components, known as a software bill of materials, and monitoring it against vulnerability databases. Software composition analysis tools flag outdated or vulnerable versions. Practices include pinning versions, verifying package integrity with checksums or signatures, removing unused dependencies, and applying updates promptly after assessing their impact. A realistic example is a logging library with a remote code execution flaw that required urgent patching across many organizations.
Security logs record events that reveal attempted or successful abuse, such as failed and successful logins, password changes, privilege modifications, access denials, input validation failures and unusual request volumes. Each entry should include a timestamp, the user or session identifier, the source address, the action and its outcome, while avoiding sensitive values such as passwords or full card numbers. Logs must be protected from tampering and retained for a period that satisfies both investigation needs and applicable privacy obligations. Central collection allows security teams to correlate events across services, and alerting rules can detect patterns such as repeated failed logins from many addresses. Good logging turns an opaque breach into a traceable sequence of decisions and actions.
Incident response for a web application generally proceeds through preparation, identification, containment, eradication, recovery and lessons learned. Preparation includes documented runbooks, contact lists, access to logs and tested backups, which determine how quickly a team can act. Identification requires distinguishing genuine compromise from noise, often by correlating alerts with application logs. Containment may involve disabling a feature, revoking tokens or blocking an attacker's addresses while preserving evidence. Eradication removes the root cause, such as patching a vulnerable endpoint, and recovery restores normal operation with monitoring for recurrence. The lessons-learned review updates controls and runbooks. Teams that rehearse these steps through tabletop exercises respond with far less confusion when a real event occurs.
In cloud hosting, the provider typically secures the physical facilities, hardware, hypervisor and core managed services, while the customer remains responsible for how it configures and uses them. For a web application, the customer usually owns the application code, its authentication logic, data classification, access policies, secrets management and the configuration of storage and networking resources. The exact boundary depends on the service model, whether infrastructure, platform or software as a service. Misunderstanding this boundary is a frequent source of breaches, such as assuming the provider has enabled encryption or access restrictions that the customer must configure. Organizations should document ownership for each control and review the provider's published responsibility matrix for their specific services.
Governance frameworks translate security goals into policies, roles and measurable controls. Widely referenced guidance includes the OWASP Application Security Verification Standard, which specifies testable requirements for authentication, session management and input handling, and the NIST Cybersecurity Framework, which organizes activities around identifying, protecting, detecting, responding and recovering. Regulatory obligations, such as data protection laws in various jurisdictions, may require specific safeguards for personal information, breach notification within set timelines and documented risk assessments. Frameworks help teams avoid ad hoc decisions by providing a common vocabulary and audit trail. However, compliance alone does not guarantee security, so organizations should treat frameworks as a baseline and tailor controls to the application's actual threats and data sensitivity.
Encryption protects data in transit through TLS, which should be configured with current protocol versions and strong cipher suites and enforced for all communication, including internal service calls. Data at rest, such as databases, file stores and backups, can be encrypted using algorithms and modes recommended by recognized standards, typically with authenticated encryption. The harder challenge is key management: keys should be stored in dedicated key management services or hardware modules, separated from the data they protect, rotated on a schedule and access-controlled. Hardcoding keys in source code is a frequent and serious mistake. Application teams should also minimize what they collect and store, because data never retained cannot be stolen. Encryption is strongest when combined with these practices rather than used as a checkbox.
Misconfiguration occurs when settings such as debug modes, default credentials, overly permissive storage access or verbose error messages are left in a production environment. Exposed secrets, including API keys, database passwords and signing keys, often appear in source repositories, client-side code or container images. These issues are common because applications pass through many environments and deployment steps, each with opportunities for drift. Good practice keeps secrets out of code and uses a dedicated vault with access logging and automatic rotation. Configuration should be defined as code, reviewed like any other change and validated against a hardened baseline before deployment. Automated secret scanning in pipelines catches accidental commits, while regular configuration audits detect settings that have drifted from the approved standard.
Threat modeling is a structured analysis that identifies what an application protects, who interacts with it, where trust boundaries lie and how an adversary might compromise it. Common methods include STRIDE, which categorizes threats as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, and attack trees that map routes to a goal. The output informs architectural decisions, such as separating public and administrative interfaces, isolating a payment component, or requiring authentication between internal services. Threat modeling is most valuable when started early and revisited as the design changes. A team designing a file upload feature, for example, would consider malicious file types, storage location and scanning before implementation, rather than discovering the risk during a penetration test.