Web Application Security in 2026: Supply Chain, Secrets and Code You Did Not Write
Most breaches at small and mid-sized companies are not clever. They are an admin endpoint that checked whether a user was logged in but never whether they were allowed, an API key committed to a repository three years ago, or a dependency that was compromised upstream and installed by a build server at two in the morning. Broken access control has sat at the top of the OWASP Top 10 for years for exactly this reason: it is boring, it is everywhere, and it does not require an attacker with a research budget.
What has changed recently is the supply chain. The economics of attacking a popular npm package are far better than attacking any single company: phish one maintainer, publish one malicious patch version, and thousands of build pipelines pull it down within hours — many of them running with credentials that can reach production. Several large-scale package compromises over the last two years have followed that exact shape, and the payload is now usually a credential harvester that scans the build environment for tokens rather than anything visible to a user.
The second change is who writes the code. A large share of new application code is now drafted by an assistant, and assistants are fluent, fast and entirely unbothered by security context. They will happily concatenate a SQL query, disable certificate verification to make a test pass, or write an endpoint that trusts a client-supplied user ID — because all of those patterns appear thousands of times in their training data. The failure is not that the code looks wrong; it is that it looks completely ordinary.
The issues we find most often in real audits :
- Authorisation checked in the UI but not enforced again in the API handler
- Object IDs taken straight from the request and used without an ownership check
- Secrets in environment files committed to the repository, or exposed to the browser bundle by a public prefix
- Long-lived cloud keys stored in CI settings instead of short-lived tokens issued per run
- No Content Security Policy, so any injected script runs with full access to the session
- Dependencies pinned by a range rather than a lockfile, and never audited after launch
- File uploads and webhooks accepted without size limits, type checks or signature verification
Frameworks are part of your attack surface too
It is tempting to treat the framework as a safe layer beneath your code, but framework-level vulnerabilities land regularly and they land hard, because every application using that version is affected at once. A middleware authorisation bypass disclosed in a major React framework in 2025 is a good example: applications that had done everything correctly in their own code could still have their authentication skipped, and the only defence was patching quickly. This is why version currency is a security control rather than housekeeping. If updating your framework is a two-week project, your effective response time to a critical advisory is two weeks.
What a proportionate security baseline looks like
Enforce authorisation at the data layer, not the route
Every query that reads or writes a record should take the acting user as an argument and filter by ownership or role. Checks scattered across route handlers are checks somebody will forget to copy into the next endpoint.
Remove long-lived credentials from the pipeline
Use short-lived, workload-identity tokens for deployments and cloud access, scope them to the smallest permission set that works, and run secret scanning on every push so a leaked key is caught in minutes rather than at the next audit.
Treat dependencies as code you are responsible for
Commit lockfiles, install with the exact-lockfile command in CI, keep automated update pull requests flowing so upgrades stay small, and hold a short cooling-off period before adopting brand-new patch versions of critical packages.
Ship a strict Content Security Policy and secure cookies
A nonce-based CSP turns most cross-site scripting from a full session takeover into a blocked console error. Pair it with HttpOnly, Secure and SameSite cookies, sensible rate limiting on authentication routes, and security headers verified in CI rather than assumed.
Review AI-generated code where it touches trust boundaries
Assistants are excellent at the parts of a codebase that are easy to verify and dangerous in the parts that are not. Authentication, authorisation, payments, file handling and anything that builds a query deserve a human reader who is specifically looking for the missing check.
None of this requires a security team. It requires the same discipline you already apply to correctness: make the safe path the default path, put the check in the layer that cannot be bypassed, and automate the parts that depend on somebody remembering. A dependency audit, a secret scan and a header check in the pipeline cost an afternoon to configure and then run forever.
What it does require is deciding who owns it. In small teams security tends to be everybody's job, which reliably means nobody reviews the advisory that arrived on a Friday. Name one person per project who reads the alerts, keep an inventory of what is deployed and which versions it runs, and agree in advance what a critical advisory is allowed to interrupt. The teams that recover quickly from a supply chain incident are almost never the ones with the best tooling; they are the ones who knew what they had installed.
If you are inheriting a codebase and want the highest-value first pass, start with access control on the three most sensitive endpoints, rotate every credential that has ever appeared in the repository history, and get the framework and its dependencies onto a supported version. That work is unglamorous and it closes the doors that are actually being tried.
Working on something like this?
Object Infotech provides web development for teams that need it from Surat, India. Custom web applications, SaaS platforms and marketing sites built on React, Next.js and Node.js. See projects we have delivered or tell us about yours.
Talk to our team