Your application runs like clockwork. Customers use it every day. Your team is developing new features. You’ve achieved success.
But are you sure your application is secure?
This isn’t about hypothetical threats or obvious scenarios like password theft. It’s about problems you can’t see – ones that may already exist today and, as a consequence, can undermine trust in your brand.
We’re talking about situations such as:
- vulnerabilities in popular frameworks
- exposure of security tokens through poorly designed mechanisms
- attacks on dependencies installed from npm
- vulnerabilities in libraries used by millions of applications, such as Axios or Nx
These are not distant scenarios. This is the present.
“If it works, don’t touch it” – the most expensive belief in IT
In many organizations, technological decisions come down to a single assumption: “if something works, there’s no point in changing it.”
From a business perspective, this sounds quite rational.
Updates cost money, take time, and may introduce the risk of new bugs. We could even say that no application is 100% secure – so why go looking for new problems?
In practice, however, the lack of updates means staying with known, publicly documented threats.
A vulnerability doesn’t depend solely on the quality of the code and the protections you’ve already put in place. Issues can be introduced without your knowledge, for example, through dependencies, mechanisms, or libraries you use.
Ultimately, it comes down to this:
it’s worth investing in updates, because subsequent versions systematically reduce the risks stemming from issues that, over time, become real threats and can significantly increase the cost of fixing them.
On top of that, older versions don’t support modern browser and library standards. This makes your product slower, and developers end up spending time “patching holes” instead of delivering new features.
💻 Don’t let an outdated frontend hurt your brand. Plan your upgrade with this article.
Recent Angular vulnerabilities
In our day-to-day work with enterprise clients at House of Angular, we see that the most expensive issues are those that result from a lack of dependency audits.
The examples below show real situations that happened quite recently. They point to something far more important than individual bugs:
Even mature and widely used solutions can contain vulnerabilities that only surface under specific conditions.
And that means one thing: application security does not depend solely on what your team has written.
SSR Race Condition: data leakage between users
In applications using server-side rendering (SSR), situations can occur where:
- one user’s data is delivered to another
- requests “overlap”
- session isolation does not work correctly
The result?
- potential data leakage
- privacy violations
- real legal risk
Such a scenario doesn’t have to look like a classic attack. It’s simply a bug that may surface under specific conditions.
Source: https://github.com/angular/angular/security/advisories/GHSA-68×2-mx4q-78m7
XSRF Token Leakage via URLs
The Angular mechanism responsible for protecting against XSRF attacks attempted to determine whether a request was same-origin based on the presence of a protocol (http://, https://).
The problem was that URLs starting with // (so-called protocol-relative URLs) were incorrectly treated as safe.
As a result, Angular automatically attached the X-XSRF-TOKEN header to requests that were, in fact, sent to external domains.
Possible risks:
- the XSRF token was sent even to third-party domains
- someone could intercept the token and then perform unauthorized POST/DELETE/PUT actions on behalf of the user –a classic CSRF scenario
It’s worth noting that the issue did not stem from a flaw in the application’s business logic, but from the mechanism that was supposed to protect it.
Source: https://github.com/angular/angular/security/advisories/GHSA-58c5-g7wp-6w37
Vulnerabilities in npm
Recently, there have been serious attacks on the npm ecosystem, in which malicious versions of popular libraries were published to the registry and could be installed like normal dependencies.
An example is the campaign described in the article S1ngularity/Nx attackers strike again, part of an attack known as Shai-Hulud: a self-replicating worm operating within the npm ecosystem.
The infected libraries contained malware capable of stealing tokens (e.g., from .npmrc files) and other sensitive environment data, such as:
- access tokens
- API keys
- environment variables
Once a token was compromised, the attacker could publish modified versions of additional libraries under the identities of their original maintainers.
As a result, the infection was not a one-time event. It propagated further along the dependency chain, “infecting” more packages and projects.
Another example is the March 2026 incident involving the Axios library. It’s worth noting upfront that Axios has around 100 million weekly downloads on npm. In this case, the issue was not a classic vulnerability in application code, but a compromise of the npm package publishing process (a supply-chain attack).
Malicious versions were published to the npm registry: axios@1.14.1 and axios@0.30.4.
The attackers added an additional dependency, plain-crypto-js, which contained a malicious script executed during package installation.
The malware acted as a RAT (Remote Access Trojan) and enabled:
- remote access to the system
- exfiltration of secrets
- takeover of GitHub and npm tokens
- access to environment variables
- compromise of CI/CD pipeline security
What made this particularly dangerous was that the malware executed at the dependency installation stage. The application didn’t even need to be run.
This incident also highlighted how dangerous automatic dependency update mechanisms can be. Many projects use version ranges such as:
"axios": "^1.14.0"which could result in automatically downloading an infected version of the library without the developer’s knowledge.
These situations show that if the right libraries become compromised and you are not actively monitoring the state of your dependencies, not only your application may be at risk, but potentially a vast portion of the internet that relies on those packages.
These types of attacks are particularly dangerous because they exploit trust in popular open-source libraries and the automation of modern development processes.
In practice, a single compromised package can become an entry point into thousands of applications, CI/CD environments, and organizations that rely on it.
📚 Read also: “How Long Does an Angular Upgrade Take and How to Keep Feature Delivery on Track.”
How can you realistically reduce the risk?
If threats can arise not only from application code, but also from frameworks, libraries, and the entire dependency ecosystem, the natural question is: what can be done about it?
Unfortunately, the answer is not as simple as “implement one tool” or “run a single audit.”
Security in modern applications is a process, not a one-time effort.
The best way to approach it is to outline good practices in a few key points:
1. Treat updates as part of your strategy, not your backlog
In many organizations, updates are pushed to the bottom of the list:
- “we’ll do it later”
- “there’s no time for it in this sprint”
- “it doesn’t deliver business value”
In practice, the opposite is true.
Each subsequent version eliminates bugs and vulnerabilities that may have remained invisible until the moment they are exploited.
That’s why companies that truly control risk:
- update regularly (small steps instead of large migrations)
- plan updates as part of the roadmap
- treat them as an investment in stability and security
2. Have visibility into your entire dependency ecosystem
Your application is not just the code written by your team.
It also includes:
- frameworks (e.g., Angular)
- libraries (e.g., Axios)
- build tools (e.g., Nx)
- dozens of packages installed via npm
Without full visibility:
- you don’t know what actually ends up in your application
- you don’t know which components are vulnerable
- you’re unable to respond in time
3. Monitor vulnerabilities continuously, not occasionally
Vulnerabilities are discovered every single day.
This means:
an application that was secure a month ago → may already contain known vulnerabilities today
That’s why it’s critical to:
- continuously monitor dependencies
- respond to newly discovered vulnerabilities
- update before the issue becomes an incident
4. Consider security in architecture, not just in code
The examples discussed earlier (SSR race conditions, token leaks) show one thing: the problem often lies not in a “line of code,” but in how the system is designed.
That’s why it’s important to:
- understand how your framework works
- use SSR, caching, and tokens consciously
- conduct architectural reviews with security in mind
5. Accept that you don’t control everything
This is the most difficult, but also the most important point.
You have no control over:
- bugs in external libraries
- vulnerabilities discovered in the future
- attacks on the ecosystem (e.g., npm)
But you do control:
- how quickly you respond
- how quickly you update
- whether you are aware of the problem at all
Risk cannot be completely eliminated. But it can be controlled.
6. Consider introducing additional standards
As application complexity grows, not only does technical risk increase, but so do requirements related to quality and compliance with established standards.
In practice, this means that security does not exist in isolation from other areas. Modern applications must meet a range of requirements that directly impact their stability, usability, and regulatory compliance.
This includes, among others:
- accessibility standards, such as WCAG, which determine whether an application is usable for all users, including those with disabilities
- performance best practices (e.g., Core Web Vitals), which affect user experience and conversion
- security and privacy standards (e.g., GDPR compliance), which carry direct legal and business consequences
- architectural consistency and code maintainability, which determine how quickly you can respond to changes and threats
From an organizational perspective, it comes down to one thing: an application that “works” but does not meet these standards effectively generates hidden debt – not only technical, but also business and legal.
💡 Read this related article → “Case Study: Angular Upgrade in a Modular SaaS Platform.”
You don’t have to do it on your own
In theory, these principles sound simple.
In practice, implementing them requires experience, knowledge of the ecosystem, and the ability to make decisions that don’t negatively impact a running business.
Many teams reach a point where managing application security begins to require expertise that goes beyond day-to-day development.
In such situations, a natural step is to seek support from teams that specialize in updates, vulnerabilities, and modern application architecture.
In practice, this means an approach that combines several key elements:
- analysis of dependencies and identification of real vulnerabilities (not just those “on paper”)
- planning updates in a way that is safe for a live system
- implementing changes without disrupting application continuity
- continuous monitoring of the ecosystem and rapid response to new threats
As a result, updates stop being a risky project and become a predictable and controlled process.
Before you plan your next sprint, make sure your foundation is stable. A professional code review helps prevent disasters before they happen.
Summary
Today’s applications are more complex than ever. They rely not only on the code your team writes, but also on an entire ecosystem of frameworks such as Angular, libraries, tools, and thousands of dependencies.
This means one thing:
security is not a state you can achieve once; it is a process that must be continuously managed, and one that is constantly required.
The vulnerabilities we’ve discussed are not exceptional. Nor are they rare.
They appear regularly, often in places no one expects:
- in security mechanisms
- in popular libraries
- in how frameworks operate
And very often, they affect applications that… work perfectly fine.
That’s why the most important question to ask today is not: “does my application work?”
But rather: do I have real control over the risk that is growing within it every day?
Organizations that ask themselves this question early enough:
- avoid costly incidents
- make informed technological decisions
- build stability that is not accidental
The rest most often learn about the problem only when it is already too late.
In a world where changes in the technology ecosystem happen every day, inaction is also a decision, often the most expensive one.
5 min
