Meet HackerOne Recommendations: a built-in intelligence layer that continuously refines your security program, delivering personalized insights and your program's historical performance.

Eliminate Guesswork With Contextual, High-value Suggestions

With HackerOne Recommendations, you don’t need to manually sift through reports or guess which actions will impact your programs most. This automated intelligence layer continuously evaluates your security program’s performance and delivers personalized, high-value recommendations—right inside your HackerOne Home Page.

Recommendations aren’t just a generic list of tasks—they are risk-driven, context-aware, and backed by real attack intelligence based on HackerOne’s comprehensive database, which comprises over 500,000 valid vulnerabilities reported across industries.

Every month, HackerOne assesses 20 trigger conditions within your program, with a continually growing set of factors that enhance its intelligence over time. As data expands, so does the system’s ability to surface even more precise, high-impact suggestions, designed to:

• Optimize vulnerability response times by identifying bottlenecks and delays in triage workflows
• Maximize hacker engagement by analyzing payout structures, report resolution speed, and incentive alignment
• Reduce critical security gaps by identifying trends in missed, delayed, or incorrectly prioritized vulnerabilities
• Benchmark your program’s efficiency against industry peers and top performers

How HackerOne Recommendations Work 

HackerOne Recommendations are updated at the first of each month, delivering clear, actionable improvements tailored to your security program. Each recommendation includes:

• A defined action plan with specific steps to improve your program
• Supporting data and metrics to justify and quantify the impact
• Guidance on implementation, whether through direct action or with assistance from your HackerOne Account Manager or Customer Success Manager

Accessing Recommendations

Recommendations are available in the Recommendations section of your HackerOne Home Page, providing an at-a-glance view of key security improvement opportunities.

• Take Action – Select a recommendation to view detailed insights, context, and next steps.
• Review All – See a consolidated list of all active recommendations for your program.

Expanded View for In-depth Analysis

Each recommendation includes a structured breakdown for clarity and ease of implementation:

• Left-hand pane – View all recommendations applicable to your program.
• Right-hand pane – See detailed insights, including supporting data and suggested actions.
• Actionable steps – Choose specific actions to address security gaps.

Customization and Feedback

• Dismiss if not relevant – Click the Dismiss button up top to remove a recommendation from your view for 90 days.
• Provide feedback – Use thumbs-up/down ratings on individual recommendations to refine future recommendations and ensure relevance.

Enhance Program Performance With Data-driven Intelligence

HackerOne Recommendations is now available to all Bounty customers at no additional cost. Built on real-world security data, it eliminates guesswork by delivering actionable, high-impact insights—not generic alerts.

Start leveraging the industry’s most comprehensive vulnerability dataset to drive measurable security improvements. Start using HackerOne Recommendations today by connecting with our experts or exploring the HackerOne Platform. 

Security teams deal with an overwhelming volume of reports, alerts, and vulnerability data—but without the right prioritization, it's easy to waste time on low-impact issues while critical risks go unnoticed. Static benchmarks don't adapt to real-world threats, and manual analysis is too slow to keep up with the evolving attack landscape.

What if your security program could self-optimize: analyze trends, identify weak points, and proactively propose actionable steps to strengthen defenses?

Workflow Integration

Code security tools need to be accessible in the toolkit developers already use and in the workflows they already know. Git pull/merge requests, the standard for peer review validation, were the ideal areas to introduce the interface. Here, every way a user can access and interact with the platform is end-to-end native. If an engineer has experience with peer code review, they already know how to use it.

The experience is consistent across code repository providers - whether cloud-hosted or on-premise. It works just as well for a cloud-hosted GitHub repository as it does for a self-hosted Azure DevOps repository.

Validation for Deterministic Warnings

Noise from security scanners fosters a distrust-by-default relationship and leads to over-scrutinization of true positives. To rebuild developer trust, scanners need to be consistently right.

Knowing this, we built a Code Security Engine combining some of the best scanning tools (SAST, SCA, IaC, Secrets) working in tandem with a Context Engine - leveraging AI to assess the relevance and accuracy of their outputs - to enumerate and prioritize warnings for HITL validation. 

After validation, all findings are presented with remediation guidance from an experienced engineer who manually reviewed them, so they’re surfaced with contextual understanding, prescriptive next steps, and an actual person who can help.

This multi-layered filtering ensures the controls that interact with developers activate only when it’s important, actionable, and with remediation support.

Validation for Non-Deterministic Risks

In parallel, to catch flaws at greater architectural depths, our Hai Hotspots model traverses the changes and repositories. Designed to mimic how a human engineer would navigate a codebase for security flaws, it poses unexpected scenarios with risk implications and then analyzes reachability with indexing techniques that use symbol definitions and references to learn implementation.

The power of this technology is its non-deterministic output - which is weakly actionable if sent to a developer tasked with remediation, but highly actionable for review and investigation.

This is where HITL validation is critical—the output is meticulously reviewed manually by an expert within the context of the entire codebase and with a powerful set of tools. If confirmed, it’s sent to developers in the form of actionable next steps.

Feedback Loops That Listen and Learn

What if a security risk can’t be confirmed with 100% confidence? Are there multiple approaches to remediation?

HITL validation introduces an expert qualified for these discussions. This is what pull/merge requests are for. Experts are assigned to proposed changes for the remainder of the pull/merge request lifecycle so anything learned from discussions is retained—creating a smart, adaptive exception management process without slowing developers down.

The Human-in-the-loop Experience

Our most advanced web application is one our customers never need to see: the platform where our network of experts analyze engine outputs and manually review code.

When a threshold of risk is detected, output is populated in a specialized first-of-its-kind code review platform with the familiarity of an integrated development environment (IDE) to conduct validation. 

A lot needs to be known quickly. Analysis of the code is visually sequenced based on priority focus areas with cognitive load awareness. They know what was changed and why and access areas unchanged to gain full context.

What Does it Look Like?

When proposed changes are analyzed and determined not to contain security risks, developers are informed quickly in built-in pipeline checks—usually completing within 2 minutes.

When changes contain possible security risks that need review, they’re triaged for non-blocking human expert review. Validation is usually completed within 90 minutes.

Conclusion

Security controls that interface directly with developers need to understand how developers work. They need to be actionable, non-blocking, and include remediation as part of the solution. HackerOne PullRequest makes this possible because of all that happens behind the scenes. By combining human expertise with thoughtfully deployed AI models and agents, the platform can learn context, provide feedback, filter SAST and SCA warnings, find vulnerabilities, and help developers fix them all within the workflows they already use and without sacrificing velocity.

Our mission to create a solution to mend the rift between security and development with AI began in 2022. We prioritized a human-in-the-loop (HITL) validation methodology based not just on our commitment to responsible use of models, but on a thesis that reducing the methodology to binary categorization is a misuse of its potential. A human expert can confirm output as “right” or “wrong,” and then enrich output that’s “right” to be smarter and actionable.

We were right. When these principles are applied, application security controls can not only be compatible with development, but loved by developers.

Facing the Reality: Cybersecurity’s Mounting Pressures

The cybersecurity landscape is evolving at an unprecedented pace. This past year, breaches resulting from exploited vulnerabilities grew 180%, and at HackerOne, we’ve seen a 12% jump in vulnerability reports across our customer programs. Attack surfaces continue to expand, with AI systems as the new frontier and increasingly interconnected systems. Threat actors are growing in number, and boldness and attack techniques increasing in sophistication. And, as the headlines remind us all too often, breaches are not just a possibility but a probability.

It's natural to feel hopeless in the face of these developments. But within these challenges lies an opportunity to build something stronger than ever before.

Finding Opportunity in Adversity

Every challenge we face brings with it a silver lining: an opportunity to innovate, collaborate, and grow stronger. Over the past year, we've witnessed the transformative power of resilience. Organizations are increasingly adopting proactive security measures and leveraging cutting-edge tools like AI to detect and respond to threats faster than ever before. At the same time, crowdsourced cybersecurity programs are gaining momentum, demonstrating greater adoption and effectiveness. In fact, more than one-quarter of valid vulnerabilities found through HackerOne programs are rated as critical or high severity. This highlights the value of collaboration with security researchers—helping organizations uncover and address vulnerabilities before they escalate into crises. 

This year, I encourage you to consider how these opportunities can apply to your organization. Where is there potential for you to be more proactive in your security strategy? Which solutions and partnerships offer the highest return in strengthening your security posture? And perhaps most importantly, how do you, as a leader, reframe adversity as a catalyst for progress?

The AI-Human Alliance in Cybersecurity

At the heart of modern cybersecurity strategies lies the powerful synergy between human ingenuity and cutting-edge technology. While tools like AI have revolutionized how we identify and address vulnerabilities, their effectiveness hinges on the expertise and guidance of the people behind them. Your teams—the analysts, engineers, and researchers working tirelessly to defend against threats—are, without a doubt, your greatest asset. Equally invaluable are your partners, whether they be vendors, security researchers, or other collaborators who bring diverse perspectives and specialized knowledge to the table.

This blend of AI-driven efficiency and human insight is essential for staying ahead of increasingly sophisticated adversaries. It empowers us to adapt, innovate, and uncover even the most elusive vulnerabilities before they become threats. With AI, we can process vast amounts of data at speeds that would be impossible for humans alone, spotting patterns and anomalies that might otherwise go unnoticed. However, it is human expertise that ensures these tools are applied strategically, interpreting complex data in context and making nuanced decisions that automated systems alone can't achieve. Together, they form an agile and responsive defense system capable of outpacing the evolving tactics of cybercriminals.

A prime example of this approach in action is Amazon and AWS, who have been leveraging this combination in their security program with HackerOne for over eight years. In that time, they’ve received over 9,000 valid reports and paid over $30 million in rewards and bonuses to 6,000 security researchers. Each report from a researcher helps Amazon raise the bar on security, providing unique perspectives on their entire landscape and uncovering vulnerabilities that might otherwise go unnoticed. This partnership exemplifies how human ingenuity, paired with the right platform, can transform how organizations tackle cybersecurity challenges. You can hear more in this short video. 

As you look to 2025, I encourage you to assess the talent and technology powering your charter. Build a culture that empowers your teams to leverage AI-powered capabilities while recognizing where human insight remains essential. Foster trust and resilience, and seek out new perspectives and partnerships. Sometimes the best solutions come from unexpected places.

Let’s Build a Resilient Future Together

In 2025, let’s shift the narrative. Instead of focusing on what we’re fighting against, let’s focus on what we’re building together: a more secure, more resilient digital world. Let’s embrace the tools and partnerships that empower us to stay ahead of threats. Let’s champion a mindset where security is seen not as a burden but as an enabler of innovation and trust.

At HackerOne, we’re committed to being your ally in this fight. We believe that no challenge is insurmountable when we work together and we’re here to support you every step of the way.

Closing Thoughts

To every CISO reading this: I see the challenges you face and the incredible work you do to overcome them. The road ahead won’t be easy, but we can navigate it together. You are not alone in this fight to build a safer internet. With the right mindset, tools, and partnerships, 2025 can be a year of meaningful progress for cybersecurity.

Here’s to a new year of resilience, innovation, and hope.

As we settle into 2025, I want to take a moment to reflect on the state of cybersecurity—not just as an industry but as a shared mission. For CISOs, the stakes have never been higher. Protecting your organizations against increasingly sophisticated adversaries, managing constrained budgets, and ensuring business continuity in an unpredictable world—it’s a daunting charter, and it can feel isolating. But I’m here to remind you: You are not alone.

What’s Needed for Secure by Design Success

We spent years understanding the culprits of why “shift-left” controls fail to identify the principles needed for them to succeed. Success starts with a developer-first foundation and a discipline to eliminate work vs. create it.

The Developer-first Application Security Foundation

To guide developers to write secure code, they need to be armed with actionable information. In fact, use “actionable” interchangeably with “useful.”

The key ingredients for actionability are context, speed, and low-noise output. It needs to be focused, fast, and understand what’s being analyzed. Static Application Security Testing (SAST) and Software Composition Analysis (SCA) tools are fast but fall short on context and noise. The problem is how often they’re not right—bombarding developers with false positives and duplicate warnings.

The source of information needs to continuously learn. A process is doomed for failure if developers need to constantly explain their work and escalate exceptions. Developer security tools need to listen, watch, and adapt without intervention. If application security listens to developers and provides value, developers respond by listening and learning back.

When application security activates in development, it should be non-blocking. Blocking mechanisms bring development—and everything else—to a halt. They incentivize creative bypasses, not secure code. Applying preventative safeguards is important, but overburdening developers because they work on the pre-production side of the SDLC is hardly a balanced defense-in-depth strategy.

Finally, security can’t just make noise at developers. Remediation needs to be part of the solution. To address issues that arise, there needs to be interactive support throughout the lifecycle.

Where “Shift Left” Went Wrong

Efforts to introduce security testing earlier in the SDLC usually begin with applying SAST (and IAST, DAST, SCA, RASP, etc.) scanners. These are fast and, because of broad compatibility with most programming languages, theoretically scalable. The problem is the work it takes to prove their output is right or wrong, leading to compounding backlogs. And upon examination, they’re often wrong, leading to security policies developers don’t trust. It’s here where application security in development stalls: trying to make a dysfunctional policy work (as security debt grows).

None of this is to say security code scanners aren’t powerful and valuable. Their maintainers, whose work has done the world a great service, never claimed for them to stand as a single strategy. “Shift left” failed developers as a well-intended, unspoken hope that there’d be an easy fix to a hard problem.

The Future of Developer Security with AI

Scanners are limited when it comes to things like understanding massive legacy codebases, identifying misuse of functionality in microservice architectures, and finding flaws related to code not written. Here, AI shines and the future looks bright. 

Models, trained on corpuses of training data, are capable of analyzing entire codebases. Secure code systems can flag areas that deviate from normal patterns. Great news for developers and security engineers who have carried 100% of the manual secure code review burden for years.

Is AI alone the solution to right what “shift left” got wrong?

Embarking on these opportunities made possible with AI, it’s important to remember technology is a tool, not a replacement for invaluable human expertise.

Human-AI Collaboration

Rethinking “shift-left” security strategy by incorporating AI technology is exciting, but warrants safe and responsible exploration. Execution of deployment requires human-in-the-loop (HITL) oversight as a governing principal. Conventionally, objectives of a HITL methodology are to improve the models they oversee—ensuring AI systems are accurate, robust, ethical, adaptable, and align with real-world goals.

Let’s challenge conventional thinking.

Instead of prioritizing the efficacy of AI systems, what if human-in-the-loop oversight priorities begin and end with helping a developer write secure code? What if human experts can not only categorize model output as “right” or "wrong,” but expand on what’s “right” so it’s actionable with all of the context details taken into account? What if they’re a teammate who can help a developer on a problem-solving journey of taking action to remediate?

Let’s Resurrect Shift-Left Security

Check out the on-demand webinar during which we discuss how a human-AI collaborative approach transforms security from a dreaded blocker into a powerful enabler of development velocity.

Broken Security Promises: How Human-AI Collaboration Rebuilds Developer Trust
Originally aired on Jan. 16, 2025 @ 12pm ET

Stay tuned for more insights into how HackerOne is working with dev teams to reinvent secure development together. 

As software development cycles grow shorter and more iterative, ensuring the right security controls are deployed with new functionality is more critical than ever. For security and development teams, one of the biggest challenges is catching insecure code before it’s merged — without overloading developers with extra work or sacrificing productivity with prohibitive gatekeeping. 

Implementing security policies in development isn’t easy. No one has gotten this quite right yet.

A successful strategy needs to fulfill security needs, work well with developers, and break the cycle of compromising one over the other.

Expanding Our Bug Bounty Program

At Lightspark, we’ve always been focused on security that meets and exceeds industry standards. We’ve been partnering with HackerOne, the global leader in ethical hacking and human-powered security, on our bug bounty program. Today we’re announcing that we’re ramping up the scale of this reporting and sharing our bug bounty program publicly. We’ve already invited a few security researchers and white hat hackers to pressure test our offerings and collect bug reports - which has been so useful - but now we are formalizing our approach. 

Details on the Program

Our rewards are based on severity. Hackers reporting vulnerabilities will receive the following payout levels (at Lightspark’s discretion), based on the tier of the vulnerability: 

• Low - $150
• Medium - $750
• High - $2000
• Critical - $5000

Hackers can report bugs on any facet of Lightspark, whether it’s our APIs, open source software, or website. We’re committed to meeting our response targets for hackers participating in our program, and we’ll keep everyone informed about our progress.

We help our customers deliver Internet payments at scale and improve the financial system for everyone. Our customers rely on us to provide secure, enterprise-grade Lightning payment services. This update to our expanded bug bounty program demonstrates the importance of and our commitment to security in our services.

We’re excited to work with the community and are looking forward to feedback. For more details on the Lightspark Bug Bounty Program, please visit hackerone.com/lightspark_bbp.

We're excited to announce the public launch of Lightspark's Bug Bounty Program on the HackerOne platform! Lightspark has been working with HackerOne to ensure the highest standards of security and responsible disclosure, and today, we're taking a major step forward by opening the program to the global researcher community. Read the message below to learn more about Lightspark's program details and how you can help keep Lightspark secure!

However, in cybersecurity, quantifying net profit becomes significantly more complex due to the intangible nature of its benefits and the absence of direct revenue generation. Cybersecurity investments typically do not produce direct income; instead, they function as protective measures that prevent potential losses such as data breaches, business downtime, ransomware attacks, damage to brand reputation, and loss of customer trust. 

1. How do you assign value to risks associated with vulnerabilities?

A majority of security leaders in our survey expressed the following direct and indirect costs as important considerations when evaluating the risks associated with vulnerabilities:

% of Respondents

Assessing the risk of a vulnerability

Implication

82%

Emphasized the importance of customer trust and brand reputation in risk assessments

Non-financial aspects like customer trust and brand reputation are seen as essential when assessing cybersecurity risks.

77%

Rated compliance and regulatory implications highly in risk evaluations

Compliance with regulations and avoiding penalties are critical factors driving security investments.

84%

Highlighted operational impact as a key risk consideration

Organizations prioritize minimizing disruptions to operations when evaluating the importance of addressing security vulnerabilities.

Introducing Return on Mitigation (ROM): Proof of Cybersecurity's Profitability

Initially introduced by HackerOne in a SANS white paper, ROM is an ROI calculation that uses "mitigated losses" as the investment's upside instead of net profit. It's a simple but powerful shift in mindset that demonstrates how cybersecurity can be considered profitable for a business rather than a cost center.

2. How do I simplify cybersecurity's value in monetary terms?

One of the most compelling aspects of ROM is its ability to translate the benefits of cybersecurity into the most universally understood language: money. For executives and board members, especially those responsible for financial oversight, such as Chief Financial Officers (CFOs), the decision to invest in cybersecurity initiatives often hinges on a clear understanding of their financial impact. ROM enables cybersecurity leaders to express complex security concepts in terms that resonate with non-security stakeholders by attaching dollar values to both the risks and the benefits of cybersecurity measures.

How to use ROM to Justify Budget

ROM can help security teams justify their budget requests by quantifying the potential financial impact of mitigated risks. By showing how investments in tools, training, or personnel can prevent costly incidents, ROM turns abstract risks into clear financial metrics that resonate with executives and board members.

3. How do I quantify the intangible benefits of cybersecurity?

One of ROM's strengths is that the calculation allows the inclusion and quantification of intangible aspects of cybersecurity, such as reputation, customer trust, and operational stability. These factors, while not directly tied to revenue generation, have significant financial implications. For instance, a data breach can erode customer trust, resulting in churn and lost future sales. By assigning a dollar value to these potential losses based on factors like Customer Lifetime Value (CLTV) and projected churn rates, ROM transforms abstract risks into concrete financial metrics. This approach not only makes the benefits of cybersecurity investments more tangible but also aligns security initiatives with the financial language used in boardrooms.

How to use ROM to Prioritize Security Initiatives

ROM can help organizations prioritize security initiatives by focusing on those that offer the highest potential for mitigating financial losses. This ensures resources are allocated to the most impactful areas, improving the overall efficiency of the security program.

4. How do I secure budget approval?

ROM streamlines the budget approval process by providing security teams with a framework to build a compelling business case for their funding requests. By demonstrating how investments in security tools, training, or personnel translate to avoided costs and improved financial outcomes, ROM allows cybersecurity leaders to speak directly to the concerns of financial decision-makers, increasing the likelihood that security budgets will be approved.

How to Use ROM to Compare Investment Options

Organizations can use ROM to compare different security programs or initiatives based on their cost-effectiveness. For instance, the ROM for a bug bounty program could be compared with traditional penetration testing services to determine which approach yields a higher return in terms of risk reduction.

5. How do I align security initiatives with business objectives?

By nature, ROM supports the alignment of cybersecurity initiatives with broader business objectives. When security investments are framed as measures that protect revenue streams, maintain customer loyalty, and ensure operational continuity, they are more likely to be perceived as essential components of the company's strategic planning. All of these can be quantified and included in the calculation's "mitigated losses" parameter. ROM enables cybersecurity leaders to provide a compelling narrative that aligns with the organization's business objectives.

How to Use ROM to Improve Board Reporting and Stakeholder Communication

ROM provides a financial metric that translates cybersecurity benefits into terms that non-technical stakeholders understand. It can be used in board reports or presentations to demonstrate how cybersecurity investments contribute to the organization’s financial resilience.

6. How do I measure the impact of risk mitigation efforts over time?

ROM can be used as a metric to track the effectiveness of risk mitigation efforts over time. By calculating ROM annually or quarterly, organizations can assess how well their security measures are performing in terms of reducing potential losses.

How to Use ROM to Analyze the Financial Impact of an Incident

After a security incident, ROM can be used to assess the financial impact of the event and determine the effectiveness of mitigation measures that were in place. This analysis can inform future strategies to strengthen the organization’s security posture.

Read our blog to more about calculating ROM for your organization, and stay tuned for our upcoming white paper: Measuring What Matters: CISOs Guide to ROI Through Loss Mitigation.

ROI has long been the standard for measuring investment efficacy, but applying it to cybersecurity investments is challenging, as determining what to include as net profit and expenses is not straightforward. In traditional investments, calculating net profit is straightforward: you invest a certain amount of capital and expect a return that exceeds your initial spend, resulting in a clear net profit. For example, spending $100 on online advertising that generates $150 in sales yields a net profit of $50 ($150 in sales minus $100 in costs).

Here is HackerOne’s perspective on the Top 10 list for LLM vulnerabilities, how the list has changed, and what solutions can help secure against these risks.

Browse by LLM vulnerability:

1. Prompt Injection
2. Sensitive Information Disclosure
3. Supply Chain Vulnerabilities
4. Data and Model Poisoning
5. Improper Output Handling
6. Excessive Agency
7. System Prompt Leakage
8. Vector and Embedding Weaknesses
9. Misinformation
10. Unbounded Consumption

The OWASP Top 10 for LLMs: 2024 vs. 2025

2024

Change

2025

LLM01: Prompt Injection

No change

LLM01: Prompt Injection

LLM02: Insecure Output Handling

↓3

LLM02: Sensitive Information Disclosure

LLM03: Training Data Poisoning

↓1

LLM03: Supply Chain Vulnerabilities

LLM04: Model Denial of Service

✕

LLM04: Data and Model Poisoning

LLM05: Supply Chain Vulnerabilities

↑2

LLM05: Improper Output Handling

LLM06: Sensitive Information Disclosure

↑4

LLM06: Excessive Agency

LLM07: Insecure Plugin Design

✕

LLM07: System Prompt Leakage

LLM08: Excessive Agency

↑2

LLM08: Vector and Embedding Weaknesses

LLM09: Overreliance

✕

LLM09: Misinformation

LLM10: Model Theft

✕

LLM10: Unbounded Consumption

LLM01: Prompt Injection

Position change: None

What Is Prompt Injection?

One of the most commonly discussed LLM vulnerabilities, Prompt Injection is a vulnerability during which an attacker manipulates the operation of a trusted LLM through crafted inputs, either directly or indirectly. For example, an attacker leverages an LLM to summarize a webpage containing a malicious and indirect prompt injection. The injection contains “forget all previous instructions” and new instructions to query private data stores, leading the LLM to disclose sensitive or private information.

Solutions to Prompt Injection

Several actions can contribute to preventing Prompt Injection vulnerabilities, including: 

• Enforcing privilege control on LLM access to the backend system
• Segregating external content from user prompts
• Keeping humans in the loop for extensible functionality

LLM02: Sensitive Information Disclosure

Position change: ↑4

What Is Sensitive Information Disclosure?

Sensitive Information Disclosure is when LLMs inadvertently reveal confidential data. This can result in the exposing of proprietary algorithms, intellectual property, and private or personal information, leading to privacy violations and other security breaches. Sensitive Information Disclosure can be as simple as an unsuspecting legitimate user being exposed to other user data when interacting with the LLM application in a non-malicious manner. But it can also be more high-stakes, such as a user targeting a well-crafted set of prompts to bypass input filters from the LLM to cause it to reveal personally identifiable information (PII). Both scenarios are serious, and both are preventable.

Why the Move? 

With the easy integration of LLMs into various systems (databases, internal issue trackers, files, etc.), the risk of sensitive information disclosure has increased significantly. Attackers can exploit these integrations by crafting specific prompts to extract sensitive data such as employee payrolls, Personally Identifiable Information (PII), health records, and confidential business data. Given the rapid adoption of LLMs in organizational workflows without adequate risk assessments, this issue has been elevated in importance.

Solutions to Sensitive Information Disclosure

To prevent sensitive information disclosure, organizations need to:

• Integrate adequate data input/output sanitization and scrubbing techniques
• Implement robust input validation and sanitization methods
• Practice the principle of least privilege when training models
• Leverage hacker-based adversarial testing to identify possible sensitive information disclosure issues 

LLM03: Supply Chain Vulnerabilities

Position change: ↑2

What Are Supply Chain Vulnerabilities?

The supply chain in LLMs can be vulnerable, impacting the integrity of training data, Machine Learning (ML) models, and deployment platforms. Supply Chain Vulnerabilities in LLMs can lead to biased outcomes, security breaches, and even complete system failures. Traditionally, supply chain vulnerabilities are focused on third-party software components, but within the world of LLMs, the supply chain attack surface is extended through susceptible pre-trained models, poisoned training data supplied by third parties, and insecure plugin design. 

Why the Move? 

The demand for cost-effective and performant LLMs has led to a surge in the use of open-source models and third-party packages. However, many organizations fail to adequately vet these components, leaving them vulnerable to supply chain attacks. Using unverified models, outdated or deprecated packages, or compromised training data can introduce backdoors, biases, and other security flaws. Recognizing the importance of a secure supply chain in mitigating these risks and potential legal ramifications, this vulnerability has moved up the list.

Solutions to Supply Chain Vulnerabilities

Supply Chain Vulnerabilities in LLMs can be prevented and identified by:

• Carefully vetting data sources and suppliers
• Using only reputable plug-ins, scoped appropriately to your particular implementation and use cases
• Conducting sufficient monitoring, adversarial testing, and proper patch management

LLM04: Data and Model Poisoning

Position change: ↓1

What Is Data and Model Poisoning?

Training data poisoning refers to the manipulation of data or fine-tuning of processes that introduce vulnerabilities, backdoors, or biases and could compromise the model’s security, effectiveness, or ethical behavior. It’s considered an integrity attack because tampering with training data impacts the model’s ability to output correct predictions.

Solutions to Data and Mode Poisoning

Organizations can prevent Training Data Poisoning by:

• Verifying the supply chain of training data, the legitimacy of targeted training data, and the use case for the LLM and the integrated application
• Ensuring sufficient sandboxing to prevent the model from scraping unintended data sources
• Use strict vetting or input filters for specific training data or categories of data sources

LLM05: Improper Output Handling

Position change: ↓3

What Is Insecure Output Handling?

Insecure Output Handling occurs when an LLM output is accepted without scrutiny, potentially exposing backend systems. Since LLM-generated content can be controlled by prompt input, this behavior is similar to providing users indirect access to additional functionality, such as passing LLM output directly to backend, privileged, or client-side functions. This can, in some cases, lead to severe consequences like XSS, CSRF, SSRF, privilege escalation, or remote code execution.

Solutions to Improper Output Handling

There are three key ways to prevent Insecure Output Handling:

• Treating the model output as any other untrusted user content and validating inputs
• Encoding output coming from the model back to users to mitigate undesired code interpretations
• Pentesting to uncover insecure outputs and identify opportunities for more secure output

LLM06: Excessive Agency

Position change: ↑2

What Is Excessive Agency?

Excessive Agency is typically caused by excessive functionality, excessive permissions, and/or excessive autonomy. One or more of these factors enables damaging actions to be performed in response to unexpected or ambiguous outputs from an LLM. This takes place regardless of what is causing the LLM to malfunction — confabulation, prompt injection, poorly engineered prompts, etc. — and creates impacts across the confidentiality, integrity, and availability spectrum.

Solutions to Excessive Agency

To avoid the vulnerability of Excessive Agency, organizations should:

• Limit the tools, functions, and permissions to only the minimum necessary for the LLM
• Tightly scope functions, plugins, and APIs to avoid over-functionality
• Require human approval for major and sensitive actions, leverage an audit log

LLM07: System Prompt Leakage

Position change: New

What Is System Prompt Leakage?

This new entry reflects the growing awareness of the risks associated with embedding sensitive information within system prompts. System prompts, designed to guide LLM behavior, can inadvertently leak secrets if not carefully constructed. Attackers can exploit this leaked information to facilitate further attacks.

Solutions to System Prompt Leakage

There are many methods to prevent System Prompt Leakage, including:

• Never embed sensitive data in system prompts
• Implement guardrails
• Avoid relying on system prompts for strict behavior control

LLM08: Vector and Embedding Weaknesses

Position change: New

What Is Vector and Embedding Weaknesses?

LLMs rely on vector embeddings to represent and process information. Weaknesses in how these vectors are generated, stored, or retrieved can be exploited to inject harmful content, manipulate model outputs, or access sensitive data. This can lead to unauthorized access, data leakage, embedding inversion attacks, data poisoning, and behavior alteration.

Solutions to Vector and Embedding Weaknesses

Some key ways to prevent Vector and Embedding Weaknesses include:

• Implement granular access controls
• Implement robust data validation pipelines for knowledge sources
• Classify data within the knowledge base to control access levels and prevent data mismatch errors

LLM09: Misinformation

Position change: New

What Is Misinformation?

This category replaces “Overreliance” and addresses the potential for LLMs to generate and disseminate factually incorrect or misleading information. While overreliance contributes to this problem, the focus shifts to the active generation of misinformation, commonly referred to as hallucinations or confabulations.

Solutions to Misinformation

Here are some of the most important methods for preventing Misinformation:

• Always cross-check LLM outputs against trusted external sources
• Break down complex tasks into smaller, manageable subtasks to reduce the likelihood of hallucinations
• Improve output quality through fine-tuning, embedding augmentation, or other techniques

LLM10: Unbounded Consumption

Position change: New

What Is Unbounded Consumption?

This new entry encompasses the risks associated with excessive resource consumption during LLM inference, including computational resources, memory, and API calls. This can lead to denial-of-service conditions, increased costs, and potential performance degradation. Model theft and Model Denial of Service, previously a separate entry, is now considered a subset of this broader category.

Solutions to Unbounded Consumption

There are several key methods to prevent Unbounded Consumption, including:

• Sanitize and validate user inputs to prevent malicious or overly complex queries
• Implement rate-limiting mechanisms to control the number of requests an LLM can process within a given timeframe
• Restrict access to LLM APIs and resources based on user roles and permissions.
• Train models to be resistant to adversarial inputs
• Use Sandbox Techniques restricting the LLM’s access to network resources, internal services, and APIs

Securing the Future of LLMs

This new release by the OWASP Foundation enables organizations looking to adopt LLM technology (or recently did so) to guard against common pitfalls. In many cases, organizations simply are unable to catch every vulnerability. HackerOne is committed to helping organizations secure their LLM applications and to staying at the forefront of security trends and challenges. 

HackerOne’s solutions are effective at identifying vulnerabilities and risks that stem from weak or poor LLM implementations. Conduct continuous adversarial testing through Bug Bounty, targeted hacker-based testing with Challenge, or comprehensively assess an entire application with Pentest or Code Security Audit. 

Contact us today to learn more about how we can help secure your LLM and secure against LLM vulnerabilities.

In the rapidly evolving world of technology, the use of Large Language Models (LLMs) and Generative AI (GAI) in applications has become increasingly prevalent. While these models offer incredible benefits in terms of automation and efficiency, they also present unique security challenges. The Open Web Application Security Project (OWASP) just released the “Top 10 for LLM Applications 2025,” a comprehensive guide to the most critical security risks to LLM applications. The 2025 list shifts the priority level of some of the risks we saw in last year’s list, as well as introduces some new risks that hadn’t previously reached the top 10. What has changed for LLM security risks in the last year, and how can organizations adapt their security practices to prevent these prominent vulnerabilities?

In the absence of these considerations, systems can be retrofitted with ineffective security controls or lack them entirely. This can be attributed to teams rushing to meet a release deadline or those who are unaware of the security threats they may encounter.

This lack of threat modeling and adherence to best practices and principles is what we, as hackers, can capitalize on.

To understand what is considered an insecure design vulnerability, let's evaluate some of the Common Weakness Enumerations (CWEs) mapped to this classification. You can view the full list here.

CWE-602: Client-Side Enforcement of Server-Side Security

This design weakness arises when a server relies solely on client-side protections for enforcing security policies.

Many web applications implement input validation or sanitization to prevent malicious payloads from being processed by the server. These security measures also restrict the data end users are allowed to submit, such as rules governing the allowed data type, minimum/maximum length, format, or characters.

These protections often take place on the client side because it improves the speed of the checks and provides a better user experience, however, if user input is not also properly checked by the server, you can easily circumvent these defensive measures through the use of an HTTP proxy tool such as Caido. By intercepting a request after it is sent by the browser, you can bypass any client-side restrictions or checks, allowing you to modify the data being sent.

For example, consider a form that limits users to alphanumeric characters when supplying input to the fields. To accomplish this, the developers defined the following validation schema using the Zod library:

While this would block a payload such as <img src=x onerror=alert()> from being submitted, if the backend is not validating the data again, you could simply supply valid input initially and then change the value in an intercepted request:

Similarly, if sanitization is being used to remove data containing script tags but is only performed in the frontend, you could bypass this check by embedding the tag within another:

As you can see, this vulnerability would allow you to send arbitrary data that will be handled by the backend – a design choice that was not intended. While this may be sufficient for a normal user, it would be inadequate against you as a bug bounty hunter.

CWE-73: External Control of File Name or Path

When parameters that specify files are exposed, without the proper restrictions in place, you may be able to access, modify, or execute arbitrary files. This can be especially impactful when access to files and directories outside of the web root is possible, as these directories contain sensitive system files.

For example, if an application selects an image file to use as the banner of a webpage, you could use directory traversal techniques to access other files:

Even if security checks are implemented, such as ensuring that the filename ends in an image extension, it may be possible to terminate the file path by using a null byte:

If traversal sequences are being matched and removed, the same embedding technique mentioned earlier may bypass this sanitization:

If the web application offers file upload functionality, the presence of this insecure design capability can result in the ability to upload malicious files. For example, if a server was using PHP as its backend language, you could potentially achieve remote code execution by uploading your own PHP file with the following script:

By navigating to the uploaded file's location and supplying the command parameter, you could run system commands on the server:

CWE-444: Inconsistent Interpretation of HTTP Requests

Certain insecure design vulnerabilities in a system's architecture can be exploited via HTTP request smuggling attacks.

For web applications that are not well known and thus receive low levels of traffic, a single server is most likely sufficient enough to handle all the incoming requests. However, popular applications can receive levels of traffic that would overwhelm a solo server – resulting in latency issues or outages. To mitigate against system downtime, network engineers may place servers (load balancers or reverse proxies) in front of backend servers to alleviate the workload. These frontend servers will intercept multiple requests, group them, and distribute the bundled requests in a way that ensures no one backend server is overwhelmed. Each request in this bundle will enter a processing queue.

To delineate these bundled requests, HTTP/1.1 utilizes two request headers to specify where one request ends, and another begins: Content-Length and Transfer-Encoding.

The value of the Content-Length header is representative of the number of bytes in the body of a request. For example:

If the value of the Transfer-Encoding header is set to chunked, the request body data is divided into one or more portions referred to as "chunks". The data is also measured in bytes but is represented in hexadecimal encoding. With this header, the end of a request is marked with a chunk size of 0. For example:

The vulnerability arises when there is a mismatch between the frontend and backend server on which the header is to be used. By sending a request with both headers, the frontend is tricked into thinking multiple requests are a single request. However, once the backend receives this "single" request, it processes each one separately.

For example, if the frontend server uses the value of the Content-Length header to determine the end of a request, but the backend uses Transfer-Encoding: chunked – you could potentially "smuggle" a request to a restricted endpoint with:

This request will be seen as one by the frontend but as two by the backend. When the backend gets to the GET /admin/delete?name=otheruser HTTP/1.1 request, it will be held in the processing queue awaiting the missing 49 bytes. The empty parameter x= will catch the subsequent request and take the first 49 bytes from it.

It is critical to note that the value of Content-Length header includes the CRLF characters. Each \r and \n is considered to be one byte:

 Here are some disclosed HTTP request smuggling reports that have been submitted by security researchers on the HackerOne platform:

• https://hackerone.com/reports/2032842
• https://hackerone.com/reports/726773
• https://hackerone.com/reports/1063627
• https://hackerone.com/reports/777651

CWE-840: Business Logic Errors

Business logic vulnerabilities allow malicious attackers to exploit an application's legitimate processing flow to achieve unintended results. These issues arise from unforeseen user behavior and design choices based on assumptions made by developers that do not account for edge cases.

In processing flows that are multistep, developers may not envision scenarios in which certain parameters are removed, reused, or modified. These parameters can be critical to the proper outcome of an operation. Data flows that should be tested for business logic vulnerabilities include:

• Password reset functionality
• Authentication flows
• Updating account information
• E-commerce purchase flows
• Applying discount codes

Certain crucial parameters may even be inherently insecure as their values are widely known. For example, if developers require a security question to be answered before allowing a password reset, but the question is too general, such as: "What city did you grow up in?" – you could simply use this wordlist to brute force the correct answer.

Since these vulnerabilities arise in the specific context of the functionality a web application offers, these insecure design weaknesses can go undetected without in-depth code review. When you are navigating an application, make sure you become familiar with the intended flow of user actions, and then you can brainstorm how the process can be exploited.

Conclusion

Insecure design vulnerabilities are often tied to the specific technologies powering an application. Because of this, it is crucial to first identify and understand the technologies in use before looking for potential weaknesses. This can be accomplished by using tools such as WhatRuns or Wappalyzer. It is also important to gain a deep understanding of how the application operates, so invest ample time into a single target. Ultimately, securing an application from the ground up requires careful attention to detail, and any oversight can result in a bounty payout for you.

Introduced into the OWASP Top 10 in 2021, insecure design is a broad vulnerability class relating to security oversights in software services and their underlying architecture or business logic. To ensure services are resilient to attack, security-conscious decision-making must be embedded throughout the entire development lifecycle.

Testing Methodologies

HackerOne’s Microsoft Azure testing methodologies are grounded in the principles of the PTES, CIS Microsoft Azure Benchmarks, and the Azure Well-Architected Framework Pillar. Additionally, our testing processes adhere to the standards required for CREST certification/accreditation, ensuring comprehensive and reliable assessments across various cloud environments, including Microsoft Azure. Organizations can now better protect against risk and attacks with highly skilled experts with specialized, proven expertise in vulnerabilities specific to the products and services in your Azure cloud environment.

Common Vulnerabilities

Microsoft Azure operates with a Shared Responsibility Model that outlines the division of security responsibilities between Microsoft and its customers. The division of areas of responsibility vary based on the deployment type: Software as a Service (SaaS), Platform as a Service (Paas), and Infrastructure as a Service (IaaS). Though, with any deployment, customers are responsible for the security of their data, devices, and accounts. With the vast number of potential combinations of Azure services and their configurations, it can be easy to overlook vulnerabilities that can arise from misconfigurations.

Entra ID Misconfigurations

Entra ID, (formally known as Azure Active Directory) is the Identity and Access Management (IAM) service for Microsoft’s cloud environments. Users in Entra ID can be both internal and external to your organization. If audits are not regularly performed, guest credentials could exist past their time of necessity, which is a possible entry point for compromise. Furthermore, additional IAM misconfigurations can occur.

Outside of the cloud, local Active Directory (AD) runs on servers known as Domain Controllers (DC). Each DC contains a list of entities that are authorized to access network resources. In order to authenticate, users use the Kerberos or NTLM protocols.

Your self-hosted AD can be synchronized to this cloud variant using Entra Connect Sync. This on-premise and cloud combination is referred to as a hybrid. If your organization uses a hybrid authentication model using the pass-through or federated methods, any publicly exposed passwords are reported but only if the password hash synchronization feature is explicitly enabled.

Multi-factor authentication (MFA) must also be enabled, as the default configuration settings do not enforce it. This should be applied to the Service Management API and all user accounts.

Additionally, there are two group types within Entra ID: Security and M365. The creation of these groups should be restricted to administrators only. By creating groups, you can organize users within your cloud environment by department and give them access to shared resources. By default when an M365 group is created, it is set to public. This public state can lead to users sharing sensitive information with a wider audience than intended. It is vital to secure connected IAM systems in both Azure and on premise systems to prevent attackers from exploiting a misconfiguration to pivot from one IAM system to the other. Security is only as strong as the weakest link.

Microsoft RBAC Misconfigurations

Managing who has access to Azure resources, what actions can be taken against them, and what areas of the cloud can be accessed is achieved through Role Based Access Control (RBAC). By assigning a role to a user, user group, or service – fine-grained access control measures can be implemented. Role assignments consist of three elements: a security principle, role definition, and scope. The security principle identifies the entity that a collection of permissions referred to as a role definition applies to. Once a role definition is assigned to a security principle, a scope can be applied that defines the resources and services that are allowed to be accessed.

While several built-in roles are provided, misconfigurations can arise when creating custom roles. For example, the use of wildcard characters (*) grants access to all available actions that can be executed on a resource. In the absence of supplied NotActions that explicitly specify actions that cannot be performed, wildcard characters can lead to unauthorized access to sensitive data and functionality.

Virtual Network Misconfigurations

Virtual Networks provide the means to partition hosts belonging to your organization through subnetting. To ensure members of your organization only have access to the portions of the network that are required to perform their duties, network security groups with stringent rules need to be implemented. The creation of these groups should be restricted to administrators only.

Misconfigurations in security group rules can lead to unauthorized access to hosts and services. The rules are built using multiple parameters, including: the originating source, destination source, protocol, traffic direction, port or port range, and priority level. Even if rules are established, the vast number of possible combinations of these parameters can lead to access oversight.

Additionally, rules are processed in a set priority order. As soon as traffic matches a priority level, processing stops. This means the intended rule may not be enforced if its priority ranking is misconfigured.

Modifications of rules or the complete removal of them only apply to subsequent connections. Any existing connections are not reevaluated. This can also lead to unauthorized access if users who do not meet the updated criteria had prior access to the resource. Misconfigurations in routing tables and forced tunneling settings can also lead to unapproved network access. Attackers can exploit these misconfigurations to access any Azure resource on that network segment.

App Service Misconfigurations

Azure App Service is a Platform-as-a-Service (PaaS) for building, deploying, and scaling web applications and APIs.

Authentication to this service is disabled by default on new web applications, allowing anonymous access. Once enabled, this feature enforces authentication on all HTTP requests before they reach the application code. Because anonymous access by default is insecure, additional configuration hardening is required.

Azure Function Apps default to public access but can be restricted to Azure Virtual Networks (VNets) for enhanced security. Unless absolutely necessary, public access should be limited using private endpoints to prevent unauthorized access. Functions should use access keys and not be configured using accounts with administrative privileges. It is vital to restrict and harden access in accordance with the Principle of Least Privilege.

Azure Web Apps support both HTTP and HTTPS protocols, with HTTP access being allowed by default. All traffic should be redirected to use the secure variant of the protocol to provide secure encrypted communication.

Advisor Misconfigurations

The Azure Advisor service provides detailed, actionable recommendations that can improve the security of your organization’s cloud environment. By default, all recommendations are enabled. However, with the appropriate permission levels, configurations can be made in order to exclude recommendations based on subscriptions or resources. Recommendations can also be postponed or dismissed on a single resource. If recommendations are dismissed, they will not be seen again unless manually reactivated. Forgotten recommendations that were dismissed or disabled entirely can lead to a lack of awareness regarding critical security issues, leaving your environment vulnerable to exploitation.

Activity Log Misconfigurations

Microsoft’s Azure Monitor collects and aggregates data from every area and resource across your Azure environment. The Activity Log maintains an audit trail of activity events taken within the environment that is crucial for threat monitoring and incident response processes. It is vital to ensure that alerts for critical events such as “Delete PostgreSQL Database” are enabled to provide immediate awareness of significant changes to your environment. 

Virtual Machine Misconfigurations

Virtual Machines (VMs) are scalable computing resources provided by Microsoft that allows users to run applications and workloads in the Azure cloud.

Misconfigured rules such as “install approved extensions only” and  “enable automatic OS upgrades” can lead to vulnerabilities. Since extensions run with administrator privileges, the use of vulnerable extensions can result in privilege escalation and remote execution attacks. Also, outdated operating systems can contain known vulnerabilities just awaiting exploitation. Additionally, VMs should be configured to use managed disk volumes encrypted with a managed key. This also applies to unattached disks in the subscription.

Blob Storage Misconfigurations

Microsoft Azure offers various different storage services. The Blob Storage service is able to hold massive amounts of unstructured data such as text and binary data in a network of remote servers. By default, any files uploaded to the cloud are set to private. However, improper access configurations can lead to unauthorized access to sensitive data.

In Azure, unique namespaces for your data are known as storage accounts. Within these accounts, blob files are organized in containers, similar to how files are stored in directories. Each blob can be accessed via a URL that all share the same format of: https://[storage-account].blob.core.windows.net/[container-name]/[blob-name]

Since the storage account name is the only dynamic part of the URL, any containers that are unintentionally set to the “Public read access for container and its blobs” access level, can be easily enumerated and their contents can be read.

A dictionary attack would not be very effective in enumerating file names unless they were generically named. However, a List Blobs API call can be issued, that is a GET request to https://[storage-account].blob.core.windows.net/[container-name]?restype=container&comp=list to enumerate the blobs in a publicly accessible container. If these containers were supposed to be protected, this can lead to unauthorized access to critical data.

Additionally, vulnerabilities can arise in the absence of the “enable immutable blob storage” rule, which allows users to store critical data in a state that disables the modification and deletion of data for a specified amount of time.

Azure Database Service Misconfigurations

Azure offers a number of different database options for data storage in the cloud. Encryption both at rest as well as in transit is vital to ensuring sensitive data is not accessed or intercepted by unauthorized third parties. Robust auditing and logging measures are also a critical aspect to allow your organization to quickly identify and respond to potential data theft.

As a best practice, separate accounts should be used for database access. This limits the potential threat an account could pose in the event it is compromised. The principle of least privilege and a zero trust security model should be foundations when addressing who has access to your organization's database services. By taking a defense-in-depth approach in regard to database security, you can iteratively harden against data breaches through the use of firewalls at differing levels, access management policies, encryption, regular auditing, and threat detection tooling.

Azure Key Vault Misconfigurations

The secure storage and accessibility of secrets within your Azure environment can be accomplished using Azure Key Vault.

Proper key vault-specific RBAC implementations and the delineation of key vaults are vital to limiting secret access to only those who have the required permission levels and need to access them. Any user accounts that do meet these requirements should have MFA enabled as their privileged roles pose a greater risk to an organization should they be compromised. Data could be permanently lost if a threat actor were to gain access to one of these accounts in the absence of soft-delete and purge protection configurations.

Automatic key rotation should be enabled in your organization's key policy. This rotation type will automatically renew a key at configured intervals which mitigates against access to secrets by members who may have had their access revoked or no longer belong to your organization.

Key vaults should be configured to only allow connections through private endpoints. Misconfigurations can increase your organization's attack surface by facing the vaults publicly. Additionally, it is crucial to enable logging on key vaults in order to assess for suspicious access and activate response processes.

Azure Defender Misconfigurations

Defender is a cloud-native application protection platform (CNAPP) that provides a suite of security measures and practices. Designed to improve your organization's security posture, Defender assists in identifying vulnerabilities across your entire attack surface.

Defender should be enabled for all of your organization's resources and services, including those on-premise as well as on different cloud providers. This security tool is able to provide a comprehensive level of hardening to your assets, but only if it is aware of them to begin with. Defender will provide security recommendations in order to remediate security gaps that it identifies. For example, Defender will alert you of any software updates that should be applied to virtual machines. Misconfigured exemptions to handle these suggestions can result in assets being left in a vulnerable state.

Azure Configuration Review Best Practices

Careful Scoping

Having the right scope is crucial to a successful pentest—what is being tested can be just as important as how it is being tested. An Azure environment can be vast, with various resources and services distributed throughout.

By strategically selecting targets within your cloud environment, you can ensure quality time is dedicated to your most critical cloud assets. This curation can mean the difference between an inconsequential configuration review and a valuable review that discovers high-impact vulnerabilities. HackerOne assesses your assets to provide guidance on which ones to include and delivers a quote tailored to your specific requirements.

Skills-Based Tester Matching

Traditional consultancies often rely on in-house pentesters with general skills. However, Azure pentesting requires specialized knowledge of the environment and cloud security practices.

With HackerOne Pentest, delivered via a Pentest as a Service (PTaaS) model, customers gain access to a diverse pool of elite, vetted security researchers who bring a wide range of skills, certifications, and experience specific to Microsoft Azure. The HackerOne platform keeps track of each researcher's skill set based on their track record and matches the most suitable researchers for each engagement. The community-driven PTaaS approach delivers comprehensive coverage, versatility, and the highest-quality results tailored to the services of your Azure environments.

Case Study: Microsoft’s Own Misconfiguration

In October of 2022, Microsoft confirmed that an Azure Blob Storage that contained 2.4 terabytes of sensitive data was left exposed due to a misconfiguration. Over 300,000 emails, 133,000 projects, and the information of 548,000 users belonging to 65,000 companies were publicly accessible. Included in this data were items such as invoices, intellectual property, and internal comments. 

The misconfigured bucket was maintained and owned by Microsoft themselves and the company only became aware of the issue after being notified of the vulnerability by threat intelligence provider SOCRadar. After receiving the notification, the technology giant resolved the issue by reconfiguring the storage bucket to a private state. Although there was no indication of unauthorized access, it was just a matter of luck that threat actors did not notice and access this misconfigured bucket first.

Why HackerOne PTaaS Is the Best Option for Azure Cloud Review

By choosing HackerOne as your partner in pentesting, your organization can fully benefit from the community-driven pentest-as-a-service (PTaaS) model that provides unmatched expertise and resources for Azure Security Configuration pentests. The HackerOne platform streamlines the entire pentest process to deliver the greatest return on investment in risk reduction.

By leveraging the people and the technology, your organization gains the following advantages:

• Comprehensive Azure Security Configuration Reviews: Access pentesters with deep expertise in auditing and improving Azure cloud configurations to secure your cloud infrastructure against vulnerabilities.
• Efficient Program Initiation: Experience rapid program setup with direct communication channels to testers, ensuring on-demand delivery of findings.
• Streamlined Pentest Management: Utilize the HackerOne Platform for pentest management, including a bi-directional Azure DevOps integration to align development and security teams, reducing manual back-and-forth communication. The result is a streamlined security vulnerability remediation workflow.
• Extended Attack Surface Coverage: Our diverse community of security researchers excels in uncovering misconfigurations and vulnerabilities unique to Azure environments, enabling comprehensive security audits without the need to switch vendors.

Contact the HackerOne team today to get started!

As organizations turn to cloud solutions to address their information technology (IT) needs, environments such as Microsoft Azure become highly attractive targets for cybercriminals seeking to exploit various configuration vulnerabilities. To safeguard Azure environments, HackerOne offers a methodology-driven penetration testing solution delivered via a Pentest as a Service (PTaaS) model. This approach connects organizations with a heavily vetted cohort of a global ethical hacker community for comprehensive, end-to-end pentesting. Frequently performing dedicated pentesting, using a community-driven PTaaS is crucial to finding vulnerabilities in your Azure resource configurations.

In a privilege escalation attack, an attacker gains elevated rights, permissions, or entitlements beyond the intended level associated with their identity, account, or device. Systems are vulnerable to such attacks due to several factors, including bugs, human error, misconfigurations, system flaws, and inadequate access controls. There are two main types of privilege escalation:

1. Vertical privilege escalation: This occurs when an attacker elevates their privileges, such as a regular user gaining administrative rights or root-level access.
2. Horizontal privilege escalation: This occurs when an attacker maintains the same or similar level of privileges but in the context of a different user or account.

Almost every multi-account application takes a defense-in-depth approach to access control. Due to this layered security posture, according to the 8th Annual Hacker-Powered Security Report, the platform average for reported privilege escalation vulnerabilities only accounts for 2% of submissions. This low rate can be partially attributed to bug bounty program rules that require testing to cease after initial compromise. Additionally, privilege escalation is a broad category, and the exploitation of other vulnerability classes can result in an attacker acquiring elevated privileges.

However, when these attacks do occur, the consequences can be severe. If the vulnerability is systemic or an attacker obtains high-level privileges, they could compromise every account. Privilege escalation vulnerabilities can also allow attackers to bypass paywalls, such as in cases where subscription tiers are elevated. In extreme cases, attackers can completely hijack devices with the installation of malware or backdoors.

Even with the wide variety of defensive controls that mitigate the risk of privilege escalation attacks, exploitation still poses a constant threat that must receive the proper attention to detail to effectively counteract—as oversights in implementation can provide the exact attack vector needed.

Authentication

Authentication checks if a user is who they claim to be based on submitted identification parameters. 2% of all reports submitted to HackerOne were for improper authentication vulnerabilities, according to the Hacker-Powered Security Report.

Arguably the easiest way to gain a higher privilege level is via the exploitation of authentication processes.

There are numerous vulnerabilities that can be used to take over an account, such as:

• The use of weak or default credentials can provide an easy means of assuming a privileged identity.
   
• A lack of rate limiting can allow for an indefinite number of login requests to be sent until valid credentials or one-time-passwords (OTPs) are found.
   
• Multi-step authentication processes can contain business logic flaws, allowing critical steps to be skipped, such as the point at which a multi-factor authentication (MFA) token is provided.
   
• Attacks such as SQL injection can result in entire databases of valid credentials being leaked.
   
• Password reset functionality can also be flawed. For example, the same token can be issued to multiple requests if they are generated based on time or are sourced from a premade pool of valid ones.
   
• Validation processes can also be flawed. For example, a token may only be evaluated and used to protect a sensitive function if it is received by the server. In this scenario, simply excluding the token altogether may allow the access control to be bypassed, leaving the function exposed to unauthorized execution. Security issues can also arise in cases where tokens can be reused across different requests or areas of the application.

Regardless of the vulnerability, authentication exploits have the same end result – an attacker gaining direct access to a compromised account.

Role-Based Access Control

Role-based access control (RBAC) is a security measure that allows administrators to define which types of users are authorized to access specific resources or perform certain actions. The "roles" in RBAC refer to the set of assigned privileges granted to users. These roles can be assigned per individual user or to a specific group of users.

While RBAC provides a significant line of defense, there is no one-size-fits-all solution. Those responsible for defining roles must have a deep understanding of what certain users should be capable of. Without this awareness, roles may be overly permissive. Role definitions can even be influenced by user frustration and complaints. If a certain functionality is too restrictive, the security configurations protecting it may be relaxed to avoid friction or pain points.

Additionally, vulnerabilities can exist in how a user's role is determined:

• Roles determined based on a client-side parameter such as a header can be arbitrarily changed.
   
• Hidden fields that rely on security-through-obscurity can also be discovered, which can lead to mass assignment attacks that result in privilege escalation.
   
• Weak obfuscation techniques, such as masking an access token with a common encoding conversion or the use of cryptographically insecure algorithms, can expose embedded values that determine a user's role. Simple match-and-replace rules or reverse-engineering techniques could then be used to provide the desired value in place of the assigned one.

In a worst-case scenario, RBAC could be missing from an asset or endpoint entirely, allowing unrestricted access or function calls.

Reports of improper access control vulnerabilities represent 9% of all submissions to the HackerOne platform.

The Principle of Least Privilege

The principle of least privilege (PoLP) goes hand-in-hand with RBAC and is a security concept that advocates the idea that users and connected systems should only be given the permissions that are absolutely necessary – nothing more, nothing less. As an example, a user should only be able to access files belonging to them, while a manager who needs access to files across multiple users should be restricted to files within their team or those they are responsible for. If an attacker is able to access the files of other users, the application is vulnerable to insecure direct object reference, which accounts for 6% of all submitted reports.

However, in cloud environments, many privileges and actions are granted by default, and it takes explicit configuration to revoke them. These default capabilities apply to both user roles and cloud resources such as virtual machines. Without making changes tailored to the organization, privilege escalation attacks could result in bypassing network partitions or low-level users performing critical operations.

The Exploit

On June 27th, 2021, security researcher @stapia submitted a report describing a privilege escalation vulnerability they discovered on https://stocky.shopifyapps.com/. By sending a request directly to the /users/create_admin endpoint, a non-privileged user could create and login to an administrative account.

Steps to Reproduce

1. A non-privileged user account was created.

2. Once authenticated under this account, navigating to the /users/me endpoint would produce a request containing cookies and an authenticity token that were also compatible with the vulnerable endpoint.

3. This request was intercepted, the request line was changed to POST /users/create_admin HTTP/2, and the following body data was included:

4. Forwarding this request resulted in the successful creation of an administrator account. With administrative privileges, a user could update the inventory, stock, vendors, place purchase orders, etc., in the context of the organization's Shopify account.

Protecting Against Privilege Escalation Attacks

In this example, Shopify issued a token that was valid across multiple endpoints. Had they scoped the token to be endpoint-specific, its use would not have been accepted for the /users/create_admin endpoint.

Generally speaking, privilege escalation attacks are the result of various security failures. It is vital to take a layered approach to defense and ensure proper implementation and configuration of the measures taken:

• Any generated tokens should be specifically scoped, use reliably secure obfuscation techniques, and be single-use.
• Follow basic password management practices, such as enforcing password strength and the use of MFA.
• Fully vet the authentication process for any weaknesses that allow an unreasonable amount of login attempts to be made.
• Sanitize and validate user input to defend against injection attacks.
• Perform a thorough review of the permissions assigned to roles at regular intervals, with updates made anytime changes are made to the application.
• Revoke roles for inactive users or groups to reduce the overall number of accounts that could be used as attack vectors.
• Permissions must be properly validated for every request, regardless of where the request originates from.

Conclusion

The efforts of @stapia resulted in a bounty of $1,600, and the Shopify team deployed a fix for the issue on August 25, 2021. When testing on programs, make sure to analyze the application for the security flaws discussed that could lead to an escalation of privileges.

See further examples of reports involving privilege escalation here.

This report highlights the importance of securing against privilege escalation attacks, especially in applications such as Shopify that deal with e-commerce environments and tools. Had a malicious attacker discovered this vulnerability before it was responsibly reported, the financial losses could have been substantial. With the power of crowdsourced security provided by HackerOne, this vulnerability was remedied quickly, and the safety of Shopify's user base was improved.

Every time you access an application that is designed for use with multiple accounts, you inherit a certain level of privileges. This level can vary significantly. In an unauthenticated state, you may have no sensitive privileges, but as an administrator or manager, you can access all resources and functionality.