Sources

Even so, without an organized approach to managing npm packages, organizations will end up facing significant risks, including security issues resulting from vulnerabilities, non-compliance with licensing, and issues with poorly maintained packages. That’s where this article comes in. ... When using npm packages across an organization, creating clear standards helps avoid issues like version conflicts and security vulnerabilities. Managing internal repositories requires a bit of a different approach to open-source community repositories. Three key practices for doing this are: **⭐ Use Scopes**: represented by prefixes like `@my-org/package-name`, these help prevent dependency confusion and ensure organizational identity. … ### npm Package Approval Flows & Connectors Using npm packages in development directly from npmjs.org is pretty common, but a *big * risk, especially at enterprise level. Quality, security, and licensing of npm packages vary widely, and could expose your projects to vulnerabilities or legal issues. The sheer number of npm packages and dependencies (potentially 1000+ in any given project) can also overwhelm your team, increasing the chance of errors and security oversights. To get around this, organizations should implement processes to make sure only approved npm packages are used in development. There are a couple of options for this: **💡 A package approval workflow** to vet and promote packages to an “approved” repository, making sure developers can only use packages assessed as safe for production **💡 Filtering npm packages** by scope to block unverified ones by default. … ## Maintaining npm Package Integrity and Safety ... Vulnerabilities in npm packages can lead to anything from data breaches or code injection attacks to unauthorized access to sensitive information. Running `npm audit` helps identify these vulnerabilities, but it can be difficult to determine which *actually * pose a risk since this only provides a severity rating, not a detailed risk assessment. Just because a package’s severity is “**high**”, doesn’t necessarily mean it’s easily exploitable. Addressing vulnerabilities shouldn’t just be a case of upgrading packages blindly, as you may just end up with new issues or broken functionality. Instead, you should be assessing each vulnerability individually, determining the actual risk it poses to your development. Package managers like ProGet can help with this process by assessing vulnerabilities based on your organization’s operational profile, and providing actionable guidance via its PVRS categorizations, avoiding the review fatigue that comes with manually assessing all of a project’s package vulnerabilities. ### npm Dependencies with Lock Files Part of managing npm dependencies is dealing with version conflicts. If one developer installs Express version `4.16.0` and another installs `4.18.0`, this can lead to compatibility issues and a broken application. Lock files (e.g., `package-lock.json`) resolve these issues by recording exact package versions, ensuring all team members work with the same environment. To make dependency management smoother, you should: ⭐ **Commit lock files regularly**: This keeps versions consistent across all environments. ⭐ **Specify precise version ranges in `package.json`**: Avoid potential conflicts and keep things predictable. ⭐ **Update dependencies regularly**: Keep your app secure and benefit from the latest features and bug fixes. ⭐ **Use a private package repository**: Using a private package repository like ProGet gives you more control over what packages get used in production. That covers the safety of packages and development, but doesn’t really make sure your npm packages meet your organization’s legal and compliance needs. ... Relying on npm tags like “`latest`” or “`next`,” when managing npm packages in development can lead to dependency conflicts and unexpected breakages. Let’s say one developer tags a pre-release version as “`alpha`” and another developer uses the same tag for a different pre-release version, the original tag can be overwritten. This is a big deal in CI/CD workflows, where unstable code can easily slip into production, causing all kinds of headaches. … ## Effective npm Management in Your Organization Managing npm packages in your organization can be tricky—security risks, legal issues, and poorly maintained packages are just the start. Throw in version conflicts and audit fatigue, and it can quickly get overwhelming. To stay ahead, it’s important to establish clear npm practices like using scoped packages, enforcing Semantic Versioning, and automating license compliance. Implementing approval workflows, running regular vulnerability assessments, and using lock files can help keep things secure. Tools like ProGet can also make the process easier and reduce risks.

We examined developers’ understanding of security risks, the practices and tools they use, the barriers to stronger security measures, and their suggestions for improving the npm ecosystem’s security. Method: We conducted an online survey with 75 npm package developers and undertook a mixed-methods approach to analyzing their responses. Results: While developers prioritize security, they perceive their packages as only moderately secure, with concerns about supply chain attacks, dependency vulnerabilities, and malicious code. Only 40% are satisfied with the current npm security tools due to issues such as alert fatigue. Automated methods such as two-factor authentication and npm audit are favored over code reviews. Many drop dependencies due to abandonment or vulnerabilities, and typically respond to vulnerabilities in their packages by quickly releasing patches. Key barriers include time constraints and high false-positive rates. … The findings revealed that supply chain attacks ranked as the main concern, followed closely by dependency vulnerabilities and malicious code injection, which are ranked second and third, respectively. In addition, the two top-ranked threats received very similar scores, indicating a high level of concern among developers. Next, respondents were presented with an optional free-text response question (#12) to specify other areas they perceive as significant security threats to npm packages. ... The themes identified are: … - • Security Tool Issues. The primary concern is alert fatigue caused by “too much noise” in security notifications, where the volume of alerts can make it difficult to identify and prioritize genuine security threats. - • Ecosystem Fragmentation. Ensuring support for multiple package managers (e.g., npm, pnpm, yarn) and JavaScript runtimes (e.g., Node, Deno, Bun) can make package maintenance challenging, which can distract developers from security concerns. … - • Tool Noise and Alert Fatigue. Respondents complained that security scanners generate too many false positives or contextually irrelevant warnings, as one respondent noted, “The security scanning system in npm is a complete joke and more of a nuisance than anything. 99% of the “vulnerabilities” are idiotic and not worthy of a real CVE.” These excessive or low-value alerts may be counterproductive, as they divert developers from conducting meaningful work. As another remarked, “way to noising and causing lots of work for maintainers.” … Summary for RQ1. Developers viewed security as important and essential, yet most rate their own packages only “Somewhat Secure.” The primary security concerns include supply chain attacks, dependency vulnerabilities, and malicious code injection. Only 40% of developers are satisfied with the current security tools for npm packages. Common issues include alert fatigue, feature gaps, and a lack of awareness about available tools. … As shown in Table 7, respondents most frequently cited time constraints as a key barrier (49 responses; 26.2%). Other notable challenges included difficulty keeping up with security updates and emerging threats (33; 17.6%) and the complexity of managing dependencies (23; 12.3%). Insufficient community support was the least cited issue, reported by only 11 respondents. In addition, security testing and balance of security with other quality attributes each received 14 responses. On average, respondents selected approximately three distinct challenges, underscoring that obstacles are multifaceted rather than isolated. … At the tool level (Table 8), the obstacle most frequently reported was a high false-positive rate in security scans (35 responses; 30.2%), followed by inaccurate vulnerability detection and limited automation for dependency management. The least reported issue was integration difficulties with CI/CD pipelines (7 responses). Comments in the “Other” category included licensing constraints, overreliance on dependencies, and tools limited to static analysis. … Summary for RQ3. Time constraints are the most frequently cited barrier to secure package development, with other challenges including difficulties in keeping up with security updates and managing dependencies. At the tool level, a high false-positive rate in security scans was the most frequently reported issue, while CI/CD integration issues are comparatively rare. … Supply Chain Vulnerabilities and Ecosystem Fragility. Our findings confirm that supply chain attacks and dependency vulnerabilities are developers’ primary concerns in the npm ecosystem, with free-text responses describing trust issues with maintainers, unmaintained dependencies, and risky post-install scripts. These results align with broader research showing that attackers exploit three main vectors: injecting vulnerabilities into dependencies, compromising build infrastructure, and targeting developers through social engineering (Williams et al., 2025). Addressing these issues necessitates better auditing tools, registry monitoring, and enhanced governance and community practices for secure maintenance. Dependency Problems and Discontinuation Decisions. There is notable variability in dependency update practices among developers: some adopt proactive, automated strategies, while others never update dependencies unless prompted by external events. This variability increases systemic risk, as outdated and abandoned dependencies persist in the ecosystem. When developers do discontinue dependencies, the most frequent drivers are package abandonment and unpatched vulnerabilities, further highlighting the fragility of the dependency network.

1) Performance Issues: npm can sometimes suffer from performance issues, especially in large-scale projects with many dependencies. Some developers find Yarn and pnpm faster. Slow installation times and high resource consumption may impact developer productivity and build times. 2) Versioning Complexity: Managing package versions and dependency conflicts can be very challenging with npm, particularly in projects with complex dependency trees. 3) Security Concerns: npm packages are not immune to security vulnerabilities, and relying on third-party code introduces potential risks to projects. 4) Dependency Bloat: npm's default behavior of installing packages locally can lead to dependency bloat, where projects accumulate unnecessary dependencies over time. Please dont take as I am defaming the NPM these are the problem I found with NPM while I was working on monorepos

Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation. Many developers feel GitHub has left npm to stagnate since its 2020 acquisition, doing just enough to keep it running while neglecting innovations. Security problems and package spam have only intensified these frustrations. Yet these newcomers face the same harsh reality that pushed npm into GitHub's arms: running a package registry costs serious money -- not just for servers, but for lawyers handling trademark fights and content moderation. ## "Problem: There are now 28 competing standards." (Score:2) ## Re: (Score:3) ... You can publish any sort of tool for others to use in their projects easily, and on the other side you can find a tool for almost anything you need. But the idea of just changing the code you fetch to suit your needs has become an extremely difficult problem to solve. You can't just go edit the code to fix it for your case and push it to your team's repo, and send a patch to the owner if you think it helps. No. Now you gotta go up to th

In December 2025, in response to the Sha1-Hulud incident, npm completed a major authentication overhaul intended to reduce supply-chain attacks. While the overhaul is a solid step forward, the changes don’t make npm projects immune from supply-chain attacks. npm is still susceptible to malware attacks – here’s what you need to know for a safer Node community. ## Let’s start with the original problem Historically, npm relied on classic tokens: long-lived, broadly scoped credentials that could persist indefinitely. If stolen, attackers could directly publish malicious versions to the author’s packages (no publicly verifiable source code needed). This made npm a prime vector for supply-chain attacks. Over time, numerous real-world incidents demonstrated this point. Shai-Hulud, Sha1-Hulud, and chalk/debug are examples of recent, notable attacks. ## npm’s solution To address this, npm made the following changes: 1. npm revoked all classic tokens and defaulted to session-based tokens instead. The npm team also improved token management. Interactive workflows now use short-lived session tokens (typically two hours) obtained via npm login, which *defaults* to MFA for publishing. 2. The npm team also encourages OIDC Trusted Publishing, in which CI systems obtain short-lived, per-run credentials rather than storing secrets at rest. … ## Two important issues remain First, people need to remember that the original attack on tools like ChalkJS was a successful MFA phishing attempt on npm’s console. If you look at the original email attached below, you can see it was an MFA-focused phishing email (nothing like trying to do the right thing and still getting burned). The campaign tricked the maintainer into sharing both the user login and one-time password. This means in the future, similar emails could get short-lived tokens, which still give attackers enough time to upload malware (since that would only take minutes). Second, MFA on publish is optional. Developers can still create 90-day tokens with MFA bypass enabled in the console, which are extremely similar to the classic tokens from before. These tokens allow you to read and write to a token author’s maintained packages. This means that if bad actors gain access to a maintainer’s console with these token settings, they can publish new, malicious packages (and versions) on that author’s behalf. This circles us back to the original issue with npm before they adjusted their credential policies. To be clear, more developers using MFA on publish is good news, and future attacks should be fewer and smaller. However, making OIDC and MFA on-publish *optional* still leaves the core issue unresolved. In conclusion, if (1) MFA phishing attempts to npm’s console still work and (2) access to the console equals access to publish new packages/versions, then developers need to be aware of the supply-chain risks that still exist. … 3. At a minimum, it would be nice to add metadata to package releases, so developers can take precautions and avoid packages (or maintainers) who do not take supply chain security measures. In short, npm has taken an important step forward by eliminating permanent tokens and improving defaults. Until short-lived, identity-bound credentials become the norm — and MFA bypass is no longer required for automation — supply-chain risk from compromised build systems remains materially present.

We examined developers’ understanding of security risks, the practices and tools they use, the barriers to stronger security measures, and their suggestions for improving the npm ecosystem’s security. ... Results: While developers prioritize security, they perceive their packages as only moderately secure, with concerns about supply chain attacks, dependency vulnerabilities, and malicious code. Only 40% are satisfied with the current npm security tools due to issues such as alert fatigue. Automated methods such as two-factor authentication and npm audit are favored over code reviews. Many drop dependencies due to abandonment or vulnerabilities, and typically respond to vulnerabilities in their packages by quickly releasing patches. Key barriers include time constraints and high false-positive rates. To improve npm security, developers seek better detection tools, clearer documentation, stronger account protections, and more education initiatives.

## 66% of developers are frustrated with AI solutions that are almost right The biggest single frustration, cited by 66% of developers, is dealing with "AI solutions that are almost right, but not quite," which often leads to the second-biggest frustration: "Debugging AI-generated code is more time-consuming" (45%) Technology → Admired and Desired ... ## Privacy, pricing and better alternatives are top reasons developers turn their back on a technology |Detraction|Overall Rank|Median Rank|Mode Rank| |--|--|--|--| |Security or privacy concerns|1|3|1| |Prohibitive pricing|2|4|1| |Availability of better alternatives|3|4|1| |Poor usability|4|4|4| |Inefficient or time-costly|5|5|5| |Outdated or obsolete technology or features|6|5|8| |Ethical concerns|7|6|8| |Lack of or sub-par API|8|6|8| |Lack of AI or AI agents|9|9|9| |Other|10|10|10| The reasons to reject a technology are nearly universal. The top three deal-breakers for all developers are security or privacy concerns (Rank 1), prohibitive pricing (Rank 2), and the availability of better alternatives (Rank 3). The lack of AI is the least important factor (Rank 9). Technology → Worked with vs. want to work with

## Common Issues with OAuth 2.0 ### Token Management: A Real Headache One of the biggest issues with OAuth 2.0 is token management. Tokens are what apps use to prove they have permission to access your stuff. But managing these tokens can be a real pain. For starters, tokens expire. That means you have to deal with refreshing them, which can be tricky. You've got to store refresh tokens securely, and that's not always easy. Plus, if a token gets compromised, you've got a security risk on your hands. … ### Security Concerns: The Elephant in the Room Security is always a big deal, and OAuth 2.0 is no exception. There are a few common security issues you need to watch out for. First up, there's the risk of token interception. If someone gets their hands on a token, they can use it to access your stuff. That's why it's so important to use HTTPS to encrypt token transmission. Then there's the issue of token storage. You've got to store tokens securely, but that's easier said than done. Storing tokens in local storage, for example, is a bad idea because it's vulnerable to XSS attacks. Another security concern is the risk of token reuse. If a token is compromised, an attacker can use it to access your stuff. That's why it's important to have a way to revoke tokens and issue new ones. … ### Implementation Challenges: It's Not Always Easy Implementing OAuth 2.0 can be a challenge, especially if you're new to it. There are a lot of moving parts, and it's easy to make mistakes. For one thing, you've got to deal with redirect URIs. These are the URLs that the user is redirected to after they authorize an app. Getting the redirect URIs right is crucial, but it's easy to mess up. Then there's the issue of handling errors. OAuth 2.0 has a lot of error codes, and you've got to handle them all. That can be a lot of work, and it's easy to miss something. Another implementation challenge is dealing with different OAuth 2.0 flows. There are a few different flows, like the authorization code flow and the implicit flow. Each flow has its own use cases and challenges, and you've got to choose the right one for your situation. … ### User Experience: Don't Forget the Users User experience is another big issue with OAuth 2.0. If the user experience is bad, users won't use your app. It's as simple as that. One common issue is the authorization prompt. This is the screen that asks the user to authorize an app. If the prompt is confusing or scary, users won't authorize the app. Another user experience issue is the redirect flow. If the redirect flow is slow or confusing, users will get frustrated and give up. Then there's the issue of token expiration. If a token expires and the user has to re-authorize the app, that's a bad user experience. You've got to handle token expiration gracefully to avoid this. Also, you've got to think about the user experience of revoking access. If a user wants to revoke access to an app, it should be easy to do. If it's not, that's a bad user experience. … Then there's the case of the confusing authorization prompt. A few years ago, a popular photo-sharing site changed its authorization prompt. The new prompt was confusing, and a lot of users thought they were being phished. The site had to revert to the old prompt to avoid losing users. Another example is the case of the slow redirect flow. A few years ago, a popular music streaming service had a slow redirect flow. Users would authorize the app and then have to wait for a long time to be redirected back to the app. A lot of users got frustrated and gave up.

Security issues in OAuth 2.0 rarely stem from problems in the specification itself. Instead, they arise from how individual applications interpret or configure OAuth in real-world environments. This article highlights seven common security pitfalls that appear frequently in real-world systems — issues that weaken defenses, undermine trust boundaries, or introduce subtle vulnerabilities that attackers can exploit. … ## 1. Choosing the Wrong Grant Type for the Scenario OAuth 2.0 offers several grant types, each intended for a specific kind of client and deployment environment. A common source of problems is using these flows without considering whether the client is public or confidential — that is, whether it can securely store secrets. A common example is using the Client Credentials grant (`client_credentials`) for user authentication. Because this flow has no end user, it is only appropriate for machine-to-machine communication. Applying it to a login flow blurs the line between a user and an application and leaves the system with no cryptographic proof of who is actually present. … ## 3. Redirect URI Pitfalls A redirect URI is the callback URL an application registers with the authorization server — for example, `https://app.example.com/auth/callback`. Problems arise when these URIs are either too permissive or incorrectly configured. *Overly permissive redirect URIs* may be accepted by some providers but are insecure in practice, especially when they include wildcards, broad domain patterns, or allow both HTTP and HTTPS — giving potential attackers more flexibility to redirect authorization codes to malicious endpoints. *Misconfigured redirect URIs*, on the other hand, may be valid or invalid and can break the flow or open the door to unintended redirection behavior. Examples include mismatched callback paths (even small differences such as a single forward slash matter), typos in the URL, and unused registered redirect URIs. Redirect URIs should be treated as strict allow-lists, matching exactly what the authorization server expects. As has been pointed out, even small inconsistencies can undermine OAuth's protections and create opportunities for token interception. ## 4. Incomplete or Incorrect Token Validation in APIs Once an access token reaches an API, proper validation is essential. APIs are responsible for verifying several core properties of every token, and security weaknesses emerge when these checks are skipped or implemented incorrectly. In ASP.NET Core, much of this validation is enabled by default, but it can still be misconfigured or overridden inadvertently. At a minimum, APIs should validate: - **Issuer (`iss`)**: ensuring the token was issued by the expected authorization server - **Audience (`aud`)**: confirming the token was intended for this API - **Expiration (`exp`)**: rejecting tokens that are expired or outside their valid window - **Signature**: verifying that the token has not been tampered with OAuth token validation may include additional checks depending on the system's architecture and requirements, but these core fields form the minimum required for an API to enforce its trust boundary. When APIs omit or weaken these checks, they may inadvertently accept tokens from the wrong tenant, tokens issued for different services, or tokens that are expired or replayed. … ## 5. Storing Tokens Insecurely on the Client Even when OAuth flows are configured correctly, applications can weaken security by storing tokens in an unsafe manner. In browser-based applications, placing tokens in `localStorage` or `sessionStorage` exposes them to any script running on the page, including malicious scripts injected through Cross-Site Scripting (XSS) attacks. A script with access to the page can read the tokens and send them to a potential attacker. … ## 6. Overly Broad Scopes and Excessive Permissions OAuth scopes determine which resources a client is allowed to access, but they are easy to misuse. A common pitfall is treating scopes as if they are roles or broad access tiers instead of precise, task-specific permissions. When scopes are defined too broadly — or when clients request more access than necessary — the system begins to violate the principle of least privilege. Overly broad scopes increase the impact of token leakage — situations where an access token is exposed to an unauthorized party. If a leaked token grants wide-ranging permissions, an attacker may be able to call multiple APIs, read or modify high-value data, or perform privileged operations. This risk grows in distributed systems, where a single access token can unlock several downstream services. A more secure pattern is to keep scopes narrowly defined and to grant only the minimum access required for each scenario. In practice, this means: - Designing small, task-specific scopes - Requiring clients to request only the permissions needed for the operation they are performing - Reviewing scope definitions periodically as APIs and access patterns evolve … ## 7. Using Long-Lived Access Tokens Long-lived access tokens are widely discouraged in the OAuth ecosystem. The longer an access token remains valid, the greater the opportunity for an attacker to steal and reuse it. Most access tokens are self-contained, so APIs will treat them as valid for their entire lifetime.

**Bad:** When requesting an Access Token the request will fail if you include any parameters that it is not expecting. Google does not require a `state` or `type` parameter when getting the token like some other APIs do and will give you a 400 Bad Request with an `invalid_request` error if they are included. … ### 37signals **Bad:** When you create the app you select which services you want your app to have access to but during the auth flow only one of the services is displayed. **Bad:** There’s no support for limiting access to read-only via scopes. The only option is full read/write for all of the apps selected. … ### Box **Bad:** The redirect URL settings requires HTTPS which can be difficult if you’re trying to test locally (for instance my test app runs on http://localhost:5001 which is accepted every where else). Box has informed me this will be resolved soon. **Bad:** Does not use scopes for read-only or read/write access (is configured with the application). Box has also told me they will be changing this once they have more than one scope.

Over the years, attackers have found ways to exploit misconfigured flows, steal tokens, and impersonate users. These vulnerabilities—and the inconsistent way OAuth 2.0 has been implemented—are a key reason why OAuth 2.1 was introduced: to streamline best practices and close common security gaps. **Read more:** OAuth Vulnerabilities and Misconfigurations (and How to Fix Them) ... OAuth 2.0 has been extended and adapted through community-driven best practices, optional security add-ons, and third-party library conventions. While flexible, this patchwork approach often led to inconsistent implementations and avoidable vulnerabilities. OAuth 2.1 was introduced to improve security and simplicity across the ecosystem. Rather than reinventing the protocol, OAuth 2.1 streamlines it, retaining only the most secure, widely adopted practices while removing outdated and risky features like the implicit and password grant types. It formalizes what secure OAuth should look like in 2025 and beyond. … ### Exact redirect URI matching OAuth 2.0 allowed flexible redirect URI matching using wildcards and substring patterns—intended to make development smoother. Unfortunately, this flexibility opened the door to **open redirect vulnerabilities**, where attackers could manipulate redirect URIs to steal tokens or impersonate apps. OAuth 2.1 requires **exact string matching** for redirect URIs. Clients must pre-register every allowed redirect URI, and the authorization server must enforce an exact match. This eliminates ambiguity and makes unauthorized redirects far harder to exploit.

Examples for such attacks include open redirector attacks, insufficient checking of redirect URIs (see Section 4.1), problems existing on mobile operating systems (where different apps can register themselves on the same URI), mix-up attacks (see Section 4.4), where the client is tricked into sending credentials to an attacker-controlled authorization server, and the fact that URLs are often stored/logged by browsers (history), proxy servers, and operating systems.¶ … This approach turned out to be more complex to implement and more error prone to manage than exact redirect URI matching. Several successful attacks exploiting flaws in the pattern matching implementation or concrete configurations have been observed in the wild (see, e.g., [research.rub2]). Insufficient validation of the redirect URI effectively breaks client identification or authentication (depending on grant and client type) and allows the attacker to obtain an authorization code or access token, either¶ - by directly sending the user agent to a URI under the attackers control, or¶ - by exposing the OAuth credentials to an attacker by utilizing an open redirector at the client in conjunction with the way user agents handle URL fragments.¶ These attacks are shown in detail in the following subsections.¶