Web Application Security Best Practices for Business Applications

What We Mean by Web Application Security

In every Kavara engagement, web application security is the set of architectural decisions, code-level practices, and operational disciplines that, taken together, prevent unauthorized access, protect data integrity, and keep the application functioning correctly under both ordinary and adversarial conditions. Web application security is the practice of designing, building, and operating web applications to prevent unauthorized access, protect sensitive data, and resist attack across the application's authentication, data, API, and infrastructure layers.

That definition draws a boundary against two adjacent concepts. Application security operates at the code, data, and authentication layers; network security operates at the infrastructure boundary — firewalls, segmentation, intrusion detection — and most modern attacks bypass it entirely by exploiting application-layer vulnerabilities. Cybersecurity is the broader discipline that includes both, plus identity and organizational practice; application security is the slice we own as a development team. The sharpest distinction is between reactive security, which patches vulnerabilities after they exist, and architectural security, which prevents categories of vulnerability from existing at all — and the architectural work is where return on investment compounds. That is why we treat security as part of how we build web applications from the first architecture session, not a phase added near the end.

We architect security across four layers. The authentication and authorization layer governs who can access the application and what they can do inside. The data layer covers encryption at rest, encryption in transit, tenant isolation, and audit logging. The API layer covers input validation, rate limiting, authentication, and schema enforcement. The infrastructure layer covers secure configuration, secret management, deployment pipeline integrity, and supply chain security. The security best practices in this guide map to those four layers, and this approach is integrated into every custom web app development services engagement we run. That framing — security as architecture across four layers — is the foundation of our argument that security is not a checklist.

Why We Treat Security as Architecture, Not a Checklist

Most web application security guidance is written as a checklist — twenty practices to implement, fifteen vulnerabilities to scan for, ten configurations to verify; we have built and inherited enough applications to know the checklist approach catches the symptoms while leaving the underlying architectural vulnerabilities in place. A checklist does not change how authorization flows through the application, where secrets live, or how a request is scoped to a tenant — the decisions that determine whether the application is defensible.

Three architectural patterns carry the security posture of every custom web application development project we build. The first is defense in depth — security at multiple independent layers so a failure at one is caught by the next; authentication enforces tenant context, middleware enforces tenant scope in every query, and database row-level security enforces tenant isolation at the data layer. The second is security as default, insecurity as exception: every architectural decision defaults to the secure option, so connections use TLS by default, API endpoints require authentication by default, and data is encrypted at rest by default. The third is minimizing the attack surface rather than only guarding it — every unnecessary endpoint, permission, and dependency increases what we have to defend, and the dependency we never installed is the supply chain vulnerability we never have to mitigate.

The OWASP Top 10:2025 update reinforces this framing, shifting emphasis toward root causes rather than symptoms and naming Software Supply Chain Failures and Mishandling of Exceptional Conditions as categories no post-development scanning can fully address. The cost argument runs the same direction. The defect-cost curve commonly attributed to the IBM Systems Sciences Institute applies to security vulnerabilities much as it does to functional defects — directionally, a flaw caught during architecture review can cost roughly one unit to fix, in testing perhaps 15 to 20 times that, and in production potentially up to 100 times higher. The exact multipliers vary by codebase and engagement, but the direction is consistent across the custom web application development work we do: the earlier a security flaw is caught, the cheaper it is to fix, and architectural security is the cheapest security.

We do still use security checklists — OWASP ASVS, our pre-launch list, compliance verification lists — but as verification of architectural decisions already in place. An architecture designed for security passes the checklist trivially. With that framing established, the rest of these web application security best practices walk through how we apply it — starting with the OWASP Top 10:2025 framework.

How We Architect Against the OWASP Top 10 in 2026

The OWASP Top 10:2025 — released in November 2025 by the Open Web Application Security Project — names the ten most critical security risks to web applications today, and we treat it as the authoritative risk reference for every application we build. Our response to each category is practitioner architecture, not a description of the vulnerability.

The 2025 update introduces two new categories — A03:2025 Software Supply Chain Failures and A10:2025 Mishandling of Exceptional Conditions — and consolidates Server-Side Request Forgery into Broken Access Control, which remains the #1 application security risk as it has been since the 2017 framework. The ten are interconnected categories of architectural concern, and we defend against each at the layer where it lives.

A01:2025 — Broken Access Control. The #1 risk in the 2025 framework, covering unauthorized data access, privilege escalation, and improper enforcement of authorization rules — now including Server-Side Request Forgery as a consolidated sub-category. How we architect against it: we enforce authorization at three independent layers — the auth token carrying tenant and role claims, application middleware running request-scoped policy evaluation, and database row-level security using PostgreSQL RLS. A request with insufficient authorization fails at the first layer; if it is bypassed, the second catches it; if both are bypassed, the database rejects the query.

A02:2025 — Security Misconfiguration. Covers exposed default accounts, unnecessary services, insecure permissions, missing security headers, and misconfigured cloud resources. How we architect against it: every configuration is infrastructure as code — Terraform or AWS CDK — so it is version-controlled, peer-reviewed, and reproducible, with no clicking through cloud consoles to provision resources. Security headers including Content Security Policy, Strict-Transport-Security, and X-Frame-Options are configured at the application layer in every deployment, and we run a pre-launch infrastructure audit against CIS Benchmarks for the relevant cloud platform.

A03:2025 — Software Supply Chain Failures. New in 2025, covering vulnerabilities introduced through dependencies, build systems, package registries, and the broader software supply chain. How we architect against it: dependency scanning through Snyk and Dependabot runs in CI on every commit, and a Software Bill of Materials is generated for every release. We hold to a minimal-dependency philosophy — we evaluate the trust posture of every package we adopt and treat each install as a security decision — and production builds run in ephemeral, audited environments rather than on developer machines.

A04:2025 — Cryptographic Failures. Covers weak or missing encryption, exposed sensitive data, and improper use of cryptographic functions. How we architect against it: encryption at rest and in transit is a default, not an option, with TLS 1.2 as the minimum for every connection and managed cloud encryption for stored data. We never roll our own cryptography — we use vetted libraries and managed key services — and field-level encryption protects the most sensitive data where database-level encryption is not sufficient.

A05:2025 — Injection. Covers SQL injection, cross-site scripting, command injection, and related input-handling failures. How we architect against it: parameterized queries and ORM query builders are mandatory across every codebase, so user input never reaches a query as concatenated string. Input is validated against an explicit schema at the API boundary, and output is context-encoded in the frontend framework, which neutralizes cross-site scripting by default in React and the other component frameworks we build with.

A06:2025 — Insecure Design. Covers missing or ineffective security controls that stem from design decisions rather than implementation bugs. How we architect against it: we run threat modeling during the design and architecture phases — before code exists — to identify abuse cases, trust boundaries, and the controls each requires. Insecure design is the category that proves the editorial position of this page; a control that was never designed cannot be added by a scanner, only by re-architecture.

A07:2025 — Identification and Authentication Failures. Covers weak credential handling, broken session management, and missing multi-factor authentication. How we architect against it: we use managed authentication services — Auth0, Clerk, WorkOS — in nearly every engagement because they implement session management, multi-factor authentication, and protocol compliance correctly and maintain it as identity standards evolve. Tokens are stored in HttpOnly cookies with secure flags, never in client-side storage exposed to cross-site scripting.

A08:2025 — Software and Data Integrity Failures. Covers unverified updates, insecure deserialization, and CI/CD pipelines that ship unvalidated code or data. How we architect against it: deployment pipelines verify artifact integrity, signed commits and protected branches gate what reaches production, and we do not deserialize untrusted data into application objects. The build pipeline is treated as part of the attack surface, which connects directly to our supply chain defenses.

A09:2025 — Security Logging and Monitoring Failures. Covers insufficient logging, missing alerting, and the inability to detect or investigate a breach in progress. How we architect against it: every authentication event, authorization decision, and sensitive-data access is logged with user context, tenant context, timestamp, and outcome, and logs flow to centralized aggregation with alerting on anomalous patterns. We treat logging as an emission of the application's security architecture, configured from the first sprint rather than retrofitted before an audit.

A10:2025 — Mishandling of Exceptional Conditions. New in 2025, covering improper error handling, failures that leak sensitive information, and conditions where the application fails into an insecure state. How we architect against it: applications fail closed, not open — an error in authorization denies access rather than granting it — and error responses return generic messages to clients while full diagnostic detail goes only to internal logs. We test exceptional paths deliberately, because the failure mode is where insecure states surface.

These categories are not independent checklist items. The defense in depth pattern we apply to Broken Access Control overlaps with the encryption we apply to Cryptographic Failures and the input validation we apply to Injection — architecting against one strengthens defenses against the others. This is why we treat the OWASP Top 10:2025 as an architectural framework in every custom web application development engagement rather than a scan-and-fix list. Broken Access Control remains the most consequential, and the authentication and authorization layer is where we apply the heaviest architectural investment.

Authentication, Authorization, and Tenant Isolation We Build For

Authentication and authorization is the architectural layer where we apply the most defense in depth — because broken access control has been the #1 OWASP risk for nearly a decade, and most production breaches we see in inherited codebases trace back to authorization failures. It is the layer we rebuild first when we inherit a codebase.

We address four architectural concerns here. Tenant context propagation is the first: when a user authenticates, the auth system issues a token carrying tenant ID, user ID, roles, and entitlement claims, and every downstream system reads tenant context from it. We follow AWS SaaS Factory's identity-and-isolation pattern — scope acquired at authentication, enforced at every resource access — and treat that propagation as a security boundary first. These patterns sit within a broader application architecture; for the general patterns across all our work, see our complete web application architecture guide.

Tenant-scoped role-based access control is the second concern. RBAC in business applications is two-dimensional — tenant-level and within-tenant — so a user can be an admin in Tenant A and a viewer in Tenant B, and the data model must support that from day one. It is most critical in the multi-tenant SaaS platforms we build, and our SaaS development services cover the tenant management and access control patterns in depth. Enterprise SSO support is the third: mid-market and enterprise customers expect SAML and OIDC integration with their identity provider — Okta, Azure AD, Google Workspace — and for B2B applications it is not optional, so we use managed auth services that implement it in days and maintain protocol compliance as providers evolve. Database-level enforcement through PostgreSQL Row-Level Security is the fourth and the third layer of defense in depth: RLS lets the database reject a query that should not reach a row's data even when application code is bypassed. That is the feature that lets us defend against authorization bugs we have not written yet.

For SOC 2, HIPAA, and enterprise contracts, every authentication event and authorization decision is logged with tenant context, timestamp, and outcome. We treat audit logging as an emission of the auth layer, not a system bolted on for compliance, which gives us SOC 2-ready audit trails without retrofit work. We have not had a tenant isolation incident in production across the custom web application development engagements we operate — defense in depth at this layer is the reason. Auth controls who can access data; the data layer controls what happens to data at rest and in transit if other layers fail.

Data Encryption and Protection We Implement by Default

In every application we build, data is encrypted at rest by default, encrypted in transit by default, and access-logged by default — the "by default" matters because making encryption optional means making insecurity easier than security, and we architect for the opposite.

We implement five data protection practices by default across our custom web application development work, and each one is an architectural decision made before development begins rather than a control retrofitted later.

Encryption at rest covers database storage encrypted through managed cloud services — AWS RDS, GCP Cloud SQL, Azure. We use customer-managed keys for compliance-sensitive engagements and field-level encryption for the most sensitive data, including PII, financial account numbers, and health information.

Encryption in transit means TLS 1.2 minimum, TLS 1.3 preferred, for every connection — client-to-application, application-to-database, application-to-API, service-to-service. We enforce it on internal connections too, because the assumption that internal networks are trusted has not been valid since cloud-native architecture became standard.

Tenant data isolation at the database layer uses PostgreSQL Row-Level Security as the default for multi-tenant applications. We move to database-per-tenant where compliance justifies the cost.

Secrets management means application secrets — API keys, database passwords, encryption keys — are never committed to repositories. We use managed secrets services such as AWS Secrets Manager and HashiCorp Vault and inject secrets at runtime.

Data minimization means we collect and retain only the data the application needs. GDPR Article 5's data minimization principle is not just compliance language but reduced attack surface, because the PII we never collected is the PII we never have to defend.

Every access to sensitive data is logged with user context, tenant context, timestamp, and purpose. For HIPAA-regulated applications, this is the audit trail the HHS Office for Civil Rights requires; for others, it is the evidence base for incident response when a tenant reports anomalous behavior. Auth controls who. Data controls what. APIs are where who and what meet under load — and where our architectural decisions get tested by every external system that integrates with our applications.

API Security: How We Build APIs That Hold Up Under Attack

APIs are the layer where modern application security gets tested most aggressively — they expose business logic to external systems, handle authentication and authorization at scale, and are increasingly the target of automated attacks probing for the weakest endpoint. An API is the part of the application a determined attacker reaches first, because it is designed to be reached programmatically.

The OWASP API Security Top 10 — a companion framework to the OWASP Top 10 for web applications — names the API-specific risks that matter most, led by broken object-level authorization, broken authentication, and unrestricted resource consumption. We architect every API we build against that framework, and across our custom web application development engagements five practices carry the work.

Authentication on every endpoint by default is the first. There are no public endpoints except explicit, named exceptions — login endpoints, signed webhooks, health checks — the inverse of the failure mode we see most often in inherited APIs.

Schema validation at the API gateway is the second. Every request is validated against an OpenAPI schema before it reaches application code, so invalid requests are rejected at the gateway, and one architectural decision defends against many categories of injection.

Rate limiting per tenant, per user, and per endpoint is the third. The gateway enforces request budgets that prevent denial-of-service and runaway client integrations, with tighter limits on authentication endpoints to prevent credential stuffing.

Object-level authorization in addition to function-level authorization is the fourth. We validate that the user has access to the function and to the specific object it operates on. The OWASP API Security Top 10 names broken object-level authorization, or BOLA, as the #1 API risk, and we make object-level checks a required pattern in every CRUD endpoint.

API key rotation and management is the fifth. Keys for service-to-service authentication are issued through managed secrets services with rotation schedules and revocation paths, and no long-lived key is embedded in client code.

BOLA does not get caught by a security scanner. It gets caught by application architecture that requires object-level checks at every layer, and by code review that treats them as non-negotiable. Architecture defines what is technically secure; compliance frameworks define what is legally and contractually required — and the architecture we apply must satisfy both.

Compliance Frameworks We Build For: SOC 2, HIPAA, PCI DSS, and GDPR

Every Kavara engagement starts with the compliance question — which frameworks the application must satisfy — because the answer is an upfront architectural input that constrains authentication, data storage, logging, and infrastructure from the first design session.

SOC 2, the AICPA framework, applies most directly to SaaS platforms serving enterprise customers. The Type II audit verifies that controls operate effectively over a 6-to-12-month period against trust service criteria — security, availability, confidentiality, processing integrity, and privacy. We architect for SOC 2 from discovery: access control, encryption, audit logging, change management, and incident response are design decisions we make before development begins, so the production-grade application we ship is audit-ready rather than retrofitted.

HIPAA, the Health Insurance Portability and Accountability Act, applies to healthcare applications handling Protected Health Information, with penalties up to $1.9 million per violation category per year under the HHS Office for Civil Rights. HIPAA compliance is architectural: encrypted storage with customer-managed keys, role-based access control enforcing minimum necessary access, audit logging of every PHI access event, and Business Associate Agreements with every subprocessor handling PHI. We architect HIPAA-compliant applications from day one. The patterns we apply across healthcare application development engagements are detailed in our healthcare practice.

PCI DSS v4.0, the Payment Card Industry Data Security Standard, applies to applications that store, process, or transmit cardholder data. The strategy we recommend most often minimizes PCI DSS scope by using a tokenization-based payment processor — Stripe, Adyen — that handles the cardholder data, so our application architecture never touches the regulated data directly. This is architecture as compliance: making the requirement structurally not apply rather than building controls to satisfy it. The PCI DSS and SOC 2 patterns we apply across fintech application development engagements are detailed in our financial services practice.

GDPR, the General Data Protection Regulation, applies to any application processing personal data of EU residents, regardless of where it is hosted. Article 25 mandates data protection by design and by default — the regulation explicitly requires architectural integration of privacy controls. We architect for GDPR through data minimization, consent management, data subject rights endpoints for access, deletion, and portability, and audit trails of data processing. GDPR most closely mirrors our editorial position: security by architecture, not by audit.

Industries carry different combinations: healthcare carries HIPAA with SOC 2, financial services carry PCI DSS and SOC 2, and SaaS carries SOC 2 with GDPR for any EU touchpoint. In our custom web application development work, this combination shapes the architecture as much as functional requirements do. Compliance defines what must be true about the security posture; security testing is how we verify the architecture achieves it.

Security Testing We Run Before Launch and Continuously After

Security testing is the verification layer that catches the gaps between the architecture we intended and the application we built — and on every custom web application development project we run it across four approaches, at multiple points in the lifecycle, not just before launch.

Static Application Security Testing (SAST) is code-level analysis that runs on every commit in CI through tools such as Semgrep, Snyk Code, or SonarQube, catching hardcoded secrets, injection patterns, and common authorization flaws at near-zero cost per scan. Dynamic Application Security Testing (DAST) is runtime analysis against deployed applications in staging through OWASP ZAP and Burp Suite, catching authentication bypass and broken access control visible only at runtime; we run it on every release candidate. Penetration testing is manual testing by qualified security engineers before launch and at every major release, finding what SAST and DAST cannot — business logic flaws, authorization bypass through unexpected request sequences. Security audits are formal assessments by qualified auditors for SOC 2, HIPAA, or PCI DSS engagements; we architect for audit-ability from the start.

We run all four because each catches a different category of vulnerability, and the cost of running them concurrently is less than the cost of one missed vulnerability that ships to production. For engagements where verification depth is the primary concern, we validate against the OWASP Application Security Verification Standard — three levels, Level 1 opportunistic, Level 2 standard, Level 3 high-assurance. Level 2 is our default; Level 3 applies to regulated industries. For how our QA practice integrates this into the broader testing process, see our quality assurance and testing process page. The emphasis shifts depending on which phase of development we are in — which brings us to how security work is distributed across our development process.

How We Approach Security in Each Phase of Development

Security work runs through every phase of our development process — not just QA before launch — and the specific security activities shift depending on which phase we are in. In custom web application development, treating security as a single pre-launch gate concentrates the work at the one point in the lifecycle where the architectural decisions that determine the outcome can no longer be changed cheaply.

In discovery and scoping, we identify which compliance frameworks apply, what data the application will handle, and what threat model we are designing for. In design and UX, we design authentication flows, permission models, and admin interfaces with security as a usability concern, because insecure UX creates security debt no backend architecture can fully offset. In architecture and tech selection, we make the heaviest decisions — authentication service, database isolation strategy, encryption approach, secrets management, infrastructure configuration. In development, SAST and secrets scanning run on every commit and security-relevant changes get heavier code review. In quality assurance, DAST runs on every release candidate, penetration testing runs before launch and major releases, and compliance audit preparation happens here. In deployment and ongoing support, monitoring, alerting, and incident response activate, and patch management and security audit cadence continue post-launch.

Security as architecture means security work is distributed across the lifecycle; security as checklist concentrates it before launch — too late to address the architectural decisions that determine the outcome. This work is distributed across our structured development process, which we cover phase by phase in our process guide. The questions that follow are the ones we get most often from CTOs evaluating security across their existing or prospective applications.

What Is the Difference Between Application Security and Network Security?

Application security operates at the code, authentication, and data layers of the software itself; network security operates at the infrastructure boundary — firewalls, network segmentation, intrusion detection — and protects the perimeter around the application. Both matter, but they solve different problems. Network security defends against attacks targeting the infrastructure; application security defends against attacks that arrive through the application's legitimate channels — API calls, user logins, web requests — and exploit vulnerabilities in the application logic itself.

The distinction matters because most modern attacks bypass network security entirely. An attacker does not need to penetrate a firewall to exploit broken access control; they send authenticated requests through the API that the application incorrectly authorizes. Network security is necessary but not sufficient. We architect for both, and cloud platforms increasingly provide network security as a managed service — security groups, VPCs, managed firewalls — which lets our work concentrate where it matters most for application risk: the application layer itself.

How Often Should You Conduct Web Application Security Testing?

In our engagements, SAST and dependency scanning run on every commit, DAST runs on every release candidate — typically every two weeks for active applications — penetration testing runs before initial launch and at every major release, around annually for most production applications, and full security audits run on the cadence the application's compliance requirements demand, annually for SOC 2 Type II and as needed for HIPAA risk assessments. Testing frequency is not a single answer; it is a cadence appropriate to each testing approach.

The cheapest tests — SAST and dependency scanning — run constantly because the cost per scan is near-zero. The most expensive tests — penetration testing and compliance audits — run on a longer cadence because the cost per test is high. The common mistake is treating security testing as an annual event: annual penetration testing without continuous SAST means six months of accumulated commits could ship vulnerabilities to production before the next test catches them. We architect for continuous security testing in CI, so the testing happens automatically, developers see results in pull requests, and security work is integrated into the development workflow rather than scheduled as a separate event.

What Are the Most Common Web Application Security Mistakes?

The web application security mistakes we see most often in the codebases we inherit from previous vendors are single-layer authorization enforcement, hardcoded secrets in source code, dependencies without an update or scanning policy, and authentication patterns that store unencrypted tokens client-side. Each one is a structural pattern, not an isolated bug.

Single-layer authorization checks access at one layer, usually application middleware, with no enforcement at the database, so a bug in one query that skips the middleware check exposes cross-tenant data. Hardcoded secrets — API keys, database passwords, encryption keys committed to source repositories — are the most common breach pattern in inherited applications, and we usually find at least one when we audit a new codebase. Unmanaged dependencies mean no scanning policy for known CVEs, no automated update mechanism, and no software bill of materials, so a dependency with a critical vulnerability ships to production because nobody is checking. Client-side token storage keeps authentication tokens in localStorage or sessionStorage where cross-site scripting vulnerabilities can extract them; tokens belong in HttpOnly cookies with appropriate security flags. Each of these is preventable through architectural decisions made before development begins — we have rebuilt enough applications around these vulnerabilities to know the patterns on sight.

Should You Use a Web Application Firewall (WAF)?

Yes — a web application firewall provides a useful additional defense layer for most production web applications, but it does not replace application-layer security architecture; in our practice, we treat a WAF as one layer of defense in depth, not as the primary security control. A WAF catches known attack patterns at the network edge — SQL injection signatures, cross-site scripting payloads, known bot patterns — and reduces the volume of malicious traffic that reaches the application.

WAFs help most for production applications facing the public internet, applications without internal SAST, DAST, and dependency scanning maturity, and applications carrying compliance requirements that explicitly mandate them, such as PCI DSS. WAFs do not help against business logic flaws — broken object-level authorization, privilege escalation through legitimate API calls — application-layer bugs in authenticated user requests, or supply chain vulnerabilities introduced through dependencies. We use WAFs such as AWS WAF and Cloudflare WAF for many production applications, but we do not rely on them as the primary security control. The WAF is the perimeter layer of defense in depth; the architectural layers covered above are what actually defend against the OWASP Top 10 categories.

Security is architectural, not a checklist. In custom web application development, the most consequential security decisions are made in the first weeks of development, before any specific vulnerability has been written, and defense in depth across authentication, data, API, and infrastructure layers is the cheapest security investment we have found. We architect against each OWASP Top 10:2025 category at the relevant layer — broken access control defended by three-layer authorization enforcement, software supply chain failures by dependency scanning and a minimal-dependency philosophy. We build for the four major compliance frameworks — SOC 2, HIPAA, PCI DSS, and GDPR — from discovery, because compliance is an architectural input, not a post-launch concern. We run security testing continuously through CI and at the cadence compliance requires. The applications we have built and operate have not had tenant isolation incidents in production, and the architecture is the reason. This security architecture is integrated into every custom application development services engagement we run — across the SaaS platforms, enterprise portals, dashboards, and inherited codebases we modernize to production-grade security posture. Reach out to Kavara to start with a security review of your application's compliance requirements, threat model, and architecture — and receive a scoped estimate that reflects the security posture your application requires.