<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>Invicti</title> <atom:link href="https://www.invicti.com/blog/feed/" rel="self" type="application/rss+xml" /> <link>https://www.invicti.com/</link> <description>Web Application and API Security For Enterprise</description> <lastBuildDate>Thu, 03 Apr 2025 12:57:08 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod> hourly </sy:updatePeriod> <sy:updateFrequency> 1 </sy:updateFrequency> <image> <url>https://cdn.invicti.com/app/uploads/2022/03/08125959/cropped-favicon-32x32.png</url> <title>Invicti</title> <link>https://www.invicti.com/</link> <width>32</width> <height>32</height> </image> <item> <title>What is the best vulnerability scanning tool?</title> <link>https://www.invicti.com/blog/web-security/what-is-best-vulnerability-scanning-tool/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Thu, 03 Apr 2025 12:56:37 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[dast-first]]></category> <category><![CDATA[vulnerability-scanner]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=103240</guid> <description><![CDATA[<p>Finding the best vulnerability scanner starts with understanding what matters most to your organization, focusing on real security risks, not theoretical noise. A DAST-first platform like Invicti enhances SAST and SCA efforts by prioritizing exploitable issues and enabling more efficient remediation.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/what-is-best-vulnerability-scanning-tool/">What is the best vulnerability scanning tool?</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p>Selecting the most suitable application and API vulnerability scanning tool is a critical cybersecurity decision shaped by the unique needs of your organization. Unlike network scanners that focus on infrastructure-level exposures, web app and API scanners target the dynamic layers where business logic, sensitive data, and user interactions live—and where attackers increasingly strike. From infrastructure size to compliance obligations and technical ecosystems, many variables influence which solution will provide effective coverage and long-term value. The right choice can streamline workflows, reduce security noise, and help teams fix the security vulnerabilities that matter most.</p> <blockquote class="wp-block-quote is-style-default is-layout-flow wp-block-quote-is-layout-flow"> <h2 class="wp-block-heading">Types of vulnerability scanners</h2> <p>In general, vulnerability scanners can be divided into two broad categories based on the assets they test:​</p> <ul class="wp-block-list"> <li>Application vulnerability scanners (DAST tools) focus on identifying runtime security flaws in websites, web applications, and APIs.​ Common vulnerabilities detected include cross-site scripting (XSS) and SQL injection.</li> <li>Network vulnerability scanners detect vulnerabilities within network infrastructures, covering servers, routers, firewalls, and other network devices.​ Common vulnerabilities detected include open ports, exposed operating system services, and vulnerable web server versions.</li> </ul> <h3 class="wp-block-heading">Examples of application security scanners</h3> <ul class="wp-block-list"> <li><a href="https://www.invicti.com/">Invicti</a>: An enterprise-grade AppSec platform that unifies DAST, SAST, SCA, and API security and integrates into automated DevOps and OpSec workflows.</li> <li><a href="https://www.acunetix.com/">Acunetix</a>: The fastest DAST scanner for smaller organizations, featuring proof-based scanning to confirm exploitable vulnerabilities.</li> <li><a href="https://www.invicti.com/vulnerability-scanner-comparison/invicti-vs-burp-suite/">Burp Suite</a>: A popular vulnerability scanning tool in the penetration testing community, designed to support deeper manual testing but not automated scanning workflows.&nbsp;</li> </ul> <h3 class="wp-block-heading">Examples of network security scanners</h3> <ul class="wp-block-list"> <li>Greenbone OpenVAS: An open-source tool offering comprehensive scanning for network vulnerabilities.&nbsp;</li> <li><a href="https://www.invicti.com/vulnerability-scanner-comparison/invicti-vs-nessus/">Tenable Nessus</a>: Popular tool for network vulnerability assessments, detecting misconfigurations and compliance issues.</li> <li>Intruder: An automated tool for continuous network scanning with proactive threat detection.</li> </ul> </blockquote> <h2 class="wp-block-heading">How to choose the best vulnerability scanning tool</h2> <p>While application vulnerability scanning can be done statically or dynamically, when talking about a web vulnerability scanner, we are talking about <a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/">dynamic application security testing (DAST)</a> tools. When choosing among the available commercial and open-source source options, consider carefully your needs and expectations to make sure you pick the solution that works for your specific organization.</p> <h3 class="wp-block-heading">Understand your organizational needs</h3> <p>Before diving into product comparisons, take a step back to assess your environment and security priorities. Organizations with sprawling infrastructures, hybrid cloud deployments, and continuous development pipelines need scanners that can handle complexity without sacrificing performance. It’s equally important to factor in regulatory requirements. Whether your organization is in finance, healthcare, or e-commerce, the tool you choose should support necessary compliance frameworks through built-in policies and exportable reports.</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <h3 class="wp-block-heading">Key vulnerability scanner features to look for</h3> <ul class="wp-block-list"> <li>A large set of mature security checks for accurate vulnerability detection in applications and API endpoints</li> <li>An extensive and regularly updated vulnerability database to catch known vulnerable components</li> <li>High accuracy with minimal false positives, ideally supported by built-in validation like Invicti’s proof-based scanning</li> <li>Automation capabilities that support continuous scanning and integrate with CI/CD pipelines</li> <li>Seamless <a href="https://www.invicti.com/integrations/">integration</a> and compatibility with other security tools, collaboration systems, and developer tools</li> <li>A clean, intuitive interface for efficient vulnerability management, triage, and remediation</li> </ul> </blockquote> <h3 class="wp-block-heading">Automation and scalability</h3> <p>All security tool vendors like to talk about scalability, but for a web application vulnerability scanner, scalability means far more than just the ability to run more scans when needed. Scalable application security testing needs to keep pace and grow with your heavily automated development efforts and pipelines. Look for platforms built to scale with your application footprint and integrate with the tools your devs use every day, no matter the changes in volume, architecture, and deployment style. This includes the ability to handle API-heavy applications and rapid release cycles without compromising scan depth, accuracy, or reliability.</p> <h3 class="wp-block-heading">Reporting, compliance, and remediation support</h3> <p>Security tools need to do more than find vulnerabilities—they must also help teams understand and act on them. The best scanners produce reports that are both technically detailed and operationally actionable, helping developers and security teams prioritize and remediate issues with confidence. For regulated industries, solutions that offer export-ready compliance reports—aligned with frameworks like PCI DSS, HIPAA, and ISO 27001—can significantly reduce the effort required for audits and reporting.</p> <h3 class="wp-block-heading">Vendor support and documentation</h3> <p>For a vulnerability scanner, not only the quality of the tool itself but also the right configuration can make the difference between great results and utter noise—or complete silence. A vendor that offers fast, informed assistance for your specific environment, along with comprehensive documentation, can help resolve any security issues quickly and optimize your use of the platform for rapid time to value. This lets you see concrete security improvements fast rather than taking weeks to get scanning to work at all.</p> <h3 class="wp-block-heading">Cost considerations</h3> <p>Licensing costs are only one part of the scanner cost equation. When evaluating the total cost of ownership, start with the time to value and then consider the time savings from automated workflows, accuracy that reduces manual triage, and ease of integration with your environment. The most valuable scanners help teams avoid wasted effort and focus directly on exploitable issues. Conversely, a free tool can get very costly in terms of time and effort to set it up and operate, not to mention the valuable developer and security engineer time wasted on dealing with false positives.</p> <h3 class="wp-block-heading">Trial and evaluation</h3> <p>Every application environment is different, making vulnerability scanner evaluation a uniquely tricky proposition. A pilot deployment guided by vendor experts is the most effective way to evaluate a tool’s real-world fit. This hands-on approach can validate detection accuracy, integration depth, ease of use, and scalability across actual workflows. Understanding how a tool performs in your actual environment is essential for judging both its technical capabilities and its operational value.</p> <h2 class="wp-block-heading">Choosing the best vulnerability scanning tool starts with a DAST-first mindset</h2> <p>While static tools like <a href="https://www.invicti.com/learn/static-application-security-testing-sast/">SAST</a> and <a href="https://www.invicti.com/learn/software-composition-analysis-sca/">static SCA</a> play a vital role in identifying code-level security weaknesses and license issues, they often generate high volumes of findings without confirming exploitability. Network security scanners, though sometimes used on applications as well, can only find a handful of application-specific runtime issues. A <a href="https://www.invicti.com/blog/web-security/meet-the-future-of-appsec-dast-first-application-security/">DAST-first approach</a> provides essential context by testing running applications to identify exploitable vulnerabilities across your real-world attack surface.</p> <p>This doesn’t mean replacing static analysis—instead, it means grounding your AppSec strategy in runtime visibility and real risk. A good DAST solution enables teams to prioritize based on exploitability, business impact, and application exposure. When paired with static testing and supported by automated validation technologies like Invicti’s proof-based scanning, DAST allows security and development teams to focus their efforts where they matter most.</p> <p>Building around a DAST-first foundation is the most balanced approach to application security, allowing organizations to amplify the effectiveness of their entire AppSec stack—reducing noise, speeding up remediation, and strengthening security posture without adding operational drag.</p> <p><a href="https://www.invicti.com/clp/resources/buyers-guide/">Get the free AppSec Buyer’s Guide and detailed checklist</a></p> <p>The post <a href="https://www.invicti.com/blog/web-security/what-is-best-vulnerability-scanning-tool/">What is the best vulnerability scanning tool?</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Meet the future of AppSec: DAST-first application security</title> <link>https://www.invicti.com/blog/web-security/meet-the-future-of-appsec-dast-first-application-security/</link> <dc:creator><![CDATA[Mike Mattos]]></dc:creator> <pubDate>Wed, 02 Apr 2025 12:54:06 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[dast]]></category> <category><![CDATA[dast-first]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=103236</guid> <description><![CDATA[<p>Being DAST-first means starting application security with validated, real-world testing that prioritizes actual exploitable risks. Invicti’s DAST-first platform leads the way towards integrating all AppSec efforts within a scalable and integrated environment that gets your teams fixing what matters most—faster and with less noise.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/meet-the-future-of-appsec-dast-first-application-security/">Meet the future of AppSec: DAST-first application security</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p>As organizations race to streamline development and get business-critical software to market faster, the need to secure web applications and APIs at scale has never been greater. Dev teams are <a href="https://devops.com/survey-finds-speed-of-software-deployment-outpacing-security/" target="_blank" rel="noreferrer noopener nofollow">working more quickly every year</a> and can’t afford to wait around for security testing. And yet, the AppSec tools many rely on today haven’t kept up—especially in the realm of <a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/">dynamic application security testing (DAST)</a>.</p> <p>Traditional DAST tools on the market today still operate as disconnected point solutions. They focus on external website scanning and reporting, leaving the rest to overwhelmed AppSec teams. These tools generate volumes of data without validation, slow down developers with false positives, and fail to integrate cleanly into CI/CD workflows. They’re reactive, noisy, and make security a bottleneck.</p> <p>At Invicti, we’re building on over two decades of DAST expertise to bring a strategic shift toward a DAST-first approach. This is more than just an innovative product direction. This is the modern way for organizations to embed security into the way they build, release, and scale software.</p> <h2 class="wp-block-heading">Traditional DAST no longer works</h2> <p>The vast majority of available DAST products were originally designed to operate as standalone tools to aid manual testing, not as automated parts of a fast-moving DevOps pipeline. They scanned production environments, flagged issues, and created long to-do lists for AppSec teams that had to sift through false positives before assigning issues to devs. That model doesn’t work anymore, and for multiple reasons:</p> <ul class="wp-block-list"> <li><strong>Too much noise</strong>: Without a way to verify exploitability, most DAST scanners overreport for fear of missing something important. This can mean scan results with hundreds of possible vulnerabilities—leaving security teams to sort through the noise because there could always be a critical issue hiding among the false alarms.</li> <li><strong>Lack of integration</strong>: Many DAST tools don’t play well with modern dev pipelines, creating friction and slowing down releases. Unless designed from the outset for integration and automation, they still need to operate as standalone tools or risk flooding developers with non-actionable alerts.</li> <li><strong>Point solution mentality</strong>: Standalone tools aren’t built to scale across large app portfolios or coordinate with other parts of the security ecosystem. This leads vendors who specialize in other approaches to application security to encourage the mindset that DAST simply doesn’t find anything and is more a checkbox than a serious tool.</li> </ul> <p>The result? Security becomes a bottleneck or—worse—a tedious formality. Developers tune out. And risk piles up as exploitable vulnerabilities are almost certain to make it through to production. In fact, <a href="https://www.invicti.com/blog/news/73-percent-organizations-to-increase-appsec-investment-in-2023-invicti-research/">research has shown</a> that 97% of DevSecOps teams ignore a real vulnerability at least once a month because they assume it’s a false positive.</p> <h2 class="wp-block-heading">Why DAST-first is the most effective way to do AppSec</h2> <p>Years ago, Invicti was the first to market a DAST that really worked at scale. Today, it is championing a DAST-first approach that goes a lot further. Being DAST-first isn’t about doing DAST alone—it’s about starting with the most accurate, scalable, and real-world-ready testing layer and tying the rest of your AppSec to this rock-solid foundation.</p> <p>Going DAST-first with the Invicti platform gives you:</p> <ul class="wp-block-list"> <li><strong>Validated results</strong>: At the heart of Invicti’s DAST-first platform is the industry’s best scan engine that uses <a href="https://www.invicti.com/clp/proof-based-scanning-whitepaper/">proof-based scanning</a> to deliver 99.98% confirmation accuracy. This gets your teams immediately fixing real, exploitable vulnerabilities without guesswork or tedious manual verification.</li> <li><strong>Dev alignment</strong>: We integrate directly into pipelines and ticketing systems with the industry’s <a href="https://www.invicti.com/integrations/">biggest set of out-of-the-box integrations</a>. When developers get real and actionable vulnerability reports directly in the trackers they use every day, security flaws become just another type of bug to be routinely fixed.</li> <li><strong>Scalability by design</strong>: Invicti supports large, complex application and API environments across multiple teams and geographies. This isn’t a point tool to test a website here or there but a full AppSec platform that can span the entire DevSecOps process across your entire organization.</li> <li><strong>The foundation of your entire AppSec program</strong>: DAST-first testing gives security teams an immediate, accurate picture of risk in production and staging environments. From there, you can layer in orchestration with other testing approaches, issue correlation, and risk-based prioritization to make sure your teams focus on issues that make the biggest difference.</li> </ul> <h2 class="wp-block-heading">Take charge of your AppSec with the first and only DAST-first platform</h2> <p>There are lots of ways to get an ineffective DAST, from legacy DAST vendors to SAST-first or network-first platforms throwing in a <a href="https://www.invicti.com/blog/web-security/meet-the-real-dast-more-than-a-checkbox/">DAST as a compliance checkbox</a>. In contrast, <strong>Invicti is purpose-built to lead with DAST</strong>. That means we start where the risk lives—in the running application—and help customers secure what matters most, faster and with less overhead.</p> <p>With Invicti, you’re not just getting another scanner to throw in your toolbox. We’re delivering an AppSec platform that works across the SDLC, bridges gaps between security and development, and scales with your application environments and your whole organization. As a true platform, we do not limit the number of concurrent scans or the number of scan engines you can run. When you’re DAST-first, you can scan as much as you like and as often as you need on the only AppSec platform that is truly built for scale.</p> <h2 class="wp-block-heading">The future of DAST-first application security</h2> <p>At Invicti, we firmly believe DAST-first is the future of AppSec—but today’s platform is only the beginning. As we evolve and grow the platform, Invicti will continue to invest in:</p> <ul class="wp-block-list"> <li>Expanding automation and orchestration to eliminate even more manual work</li> <li>Applying multi-signal correlation to use DAST as the fact-checker and force-multiplier for your <a href="https://www.invicti.com/learn/static-application-security-testing-sast/">SAST</a>, <a href="https://www.invicti.com/learn/software-composition-analysis-sca/">SCA</a>, and other security testing tools</li> <li>Building out existing risk-driven prioritization that focuses teams on what matters</li> </ul> <p>We believe that accurate, automated DAST should be the foundation of every modern AppSec program. The future of security belongs to those who can move fast, ship safely, and scale confidently—and that future is DAST-first.&nbsp;</p> <a class="invicti-block button-block btn btn--primary" href="https://www.invicti.com/get-demo/" target="_self" title="Get a demo of DAST-first AppSec that scales with your organization" id="btn_67ef8d8dad31e" > Get a demo of DAST-first AppSec that scales with your organization </a> <p>The post <a href="https://www.invicti.com/blog/web-security/meet-the-future-of-appsec-dast-first-application-security/">Meet the future of AppSec: DAST-first application security</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Broken access control: The leading OWASP Top 10 security risk</title> <link>https://www.invicti.com/blog/web-security/broken-access-control/</link> <dc:creator><![CDATA[Jesse Neubert]]></dc:creator> <pubDate>Fri, 28 Mar 2025 13:40:48 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[owasp-top-10]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=103218</guid> <description><![CDATA[<p>Application security flaws classified as broken access control weaknesses are the most impactful risk category in the OWASP Top 10. This article shows how attackers can exploit access control gaps, lists high-profile data breaches caused by such attacks, and gives best practices for preventing and mitigating broken access control vulnerabilities.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/broken-access-control/">Broken access control: The leading OWASP Top 10 security risk</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <h2 class="wp-block-heading"><strong>Preventing broken access control vulnerabilities TLDR</strong></h2> <p>Broken access control vulnerabilities are a vast family of web application security flaws that can expose sensitive data, compromise accounts, and grant unauthorized privileges. To prevent and mitigate these risks, organizations should:</p> <ul class="wp-block-list"> <li>Implement server-side authentication and authorization checks</li> <li>Enforce role-based access control (RBAC) and the principle of least privilege to limit privilege escalation potential</li> <li>Regularly audit access logs for anomalies</li> <li>Use multi-factor authentication (MFA) to minimize the risk of unauthorized access</li> <li>Test for <a href="https://www.invicti.com/learn/insecure-direct-object-references-idor/">IDOR</a>, <a href="https://www.invicti.com/learn/directory-traversal-path-traversal/">directory traversal</a>, and other URL-based access flaws using <a href="https://www.invicti.com/blog/web-security/10-best-dast-tools/">DAST scanners</a> and manual penetration testing</li> </ul> <h2 class="wp-block-heading"><strong>Understanding access control</strong></h2> <p>Access control refers to the enforcement of restrictions that define who or what is permitted to interact with specific resources or perform particular actions. In web applications, access control relies on three fundamental mechanisms:</p> <ul class="wp-block-list"> <li>Authentication: Verifies a user’s identity to ensure they are who they claim to be</li> <li>Session management: Tracks and associates subsequent HTTP requests with the authenticated user</li> <li>Authorization: Checks whether the authenticated user has permission to execute a given action or retrieve a resource</li> </ul> <p>Access control issues remain a widespread class of severe security weaknesses. Implementing effective access control requires balancing business, organizational, and legal constraints with technical enforcement. Deciding who can gain access to what is determined by business logic, so access control flaws are often caused by insecure design or implementation not keeping up with changing business requirements.</p> <h2 class="wp-block-heading"><strong>Types of access control in web applications</strong></h2> <p>Access control mechanisms ensure that users can only perform actions and access resources within their designated permissions. These controls are categorized into three primary types: vertical, horizontal, and context-dependent access controls. Each of these access control mechanisms plays a vital role in maintaining security, enforcing business policies, and preventing unauthorized access or actions in web applications.</p> <h3 class="wp-block-heading"><strong>Vertical access controls</strong></h3> <p>Vertical access controls enforce tiered permissions, restricting sensitive functionalities to specific user roles.</p> <p>With this approach, different categories of users have distinct levels of access. For instance, an administrator might have privileges to modify or delete any user account, whereas a standard user is limited to managing only their own profile. These controls help enforce security principles like least privilege and separation of duties, ensuring users only access what is necessary for their role.</p> <h3 class="wp-block-heading"><strong>Horizontal access controls</strong></h3> <p>Horizontal access controls regulate access to data and resources among users of the same role or level.</p> <p>For example, in an online banking platform, users can only view and manage their own accounts but are restricted from accessing another user’s financial details. These controls ensure data isolation and privacy, preventing unauthorized data access within the same permission level.</p> <h3 class="wp-block-heading"><strong>Context-dependent access controls</strong></h3> <p>Context-dependent access controls adapt based on application state or user interactions, ensuring actions occur in the correct sequence.</p> <p>For example, an e-commerce platform might restrict users from modifying their shopping cart after finalizing payment. Similarly, an application might prevent users from submitting the same form multiple times to reduce fraud risks or prevent data inconsistencies.</p> <h2 class="wp-block-heading"><strong>Types of attacks exploiting broken access control&nbsp;</strong></h2> <p>Attackers exploit weak or missing access control mechanisms in various ways. The <em>Broken Access Control</em> category in the <a href="https://www.invicti.com/blog/web-security/what-owasp-top-ten-2021-categories-mean/">OWASP Top 10</a> (A01:2021) encompasses over 30 distinct types of weaknesses (CWEs), spanning missing or misconfigured authorization checks, predictable identifiers, insecure default settings, excessive privileges, flawed enforcement logic in workflows or APIs and more. Attacks targeting such weaknesses can use one or many of the following exploit techniques.</p> <h3 class="wp-block-heading">Privilege escalation exploits</h3> <h4 class="wp-block-heading">Vertical privilege escalation</h4> <p>Vertical privilege escalation happens when a user gains access to a higher level of functionality that should be restricted. For example, if a regular user can navigate to an admin dashboard and delete accounts, they have successfully exploited a vertical privilege escalation flaw.</p> <h4 class="wp-block-heading">Exposed administrative features</h4> <p>One of the simplest causes of vertical privilege escalation is unprotected administrative functionality. Some applications fail to enforce role-based access control (RBAC) and make administrative features accessible via direct URLs.</p> <p>For example, an application may host an admin panel at <code>https://insecure-website.com/admin</code>. If the application does not check whether the requesting user is really an administrator, anyone with knowledge of the URL can access it. Worse, some applications may inadvertently disclose these URLs in publicly available files, such as <code>robots.txt</code> to prevent crawlers from indexing internal app functionality. Even if the URL isn’t directly exposed, attackers can use brute-force techniques to guess common admin paths and exploit weak access controls.</p> <h3 class="wp-block-heading"><strong>Attempted security through obscurity</strong></h3> <p>Some applications may try to protect sensitive pages by assigning obscure URLs instead of enforcing proper authentication, for example:</p> <pre class="wp-block-code"><code>https:&#047;&#047;insecure-website.com/administrator-panel-xy329</code></pre> <p>While this may seem secure at first glance, attackers have many ways to discover the hidden URL:</p> <ul class="wp-block-list"> <li>JavaScript exposure: If the application references the URL in client-side scripts, it becomes visible to all users.</li> <li>Network traffic inspection: Attackers can monitor requests to detect sensitive pages.</li> <li>Wordlist brute-forcing: Automated tools can scan for common naming patterns.</li> <li>Forced enumeration: If part of the URL is known, as in the example above, the “secret” part can be found by enumeration.</li> </ul> <p>A proper security model requires explicit authentication and authorization checks, not just hiding endpoints.</p> <h3 class="wp-block-heading"><strong>Exploiting access control vulnerabilities via request manipulation</strong></h3> <h4 class="wp-block-heading">Parameter-based access control bypass</h4> <p>Some applications put user privileges in modifiable request parameters, allowing attackers to escalate their permissions by altering values in:</p> <ul class="wp-block-list"> <li>Hidden form fields</li> <li>Cookies</li> <li>Query strings</li> </ul> <p>For example, a user might see the following URL after logging in:</p> <pre class="wp-block-code"><code>https:&#047;&#047;insecure-website.com/login/home.jsp?role=1</code></pre> <p>If the application determines privileges solely based on this parameter, an attacker could try modifying <code>role=1</code> to <code>role=2</code> or another value and potentially gain unauthorized access.</p> <h4 class="wp-block-heading">Exploiting platform misconfigurations</h4> <p>Some applications enforce access control at the platform level by restricting certain URLs or HTTP methods based on user roles. However, misconfigurations can allow such safeguards to be bypassed.</p> <p>For instance, an application might restrict users with a manager role from executing a <code>DELETE</code> request on the user management page:</p> <pre class="wp-block-code"><code>DENY: POST, /admin/deleteUser, managers</code></pre> <p>If the access control mechanism is misconfigured, attackers might bypass this by:</p> <ul class="wp-block-list"> <li>Overriding the request URL using headers like <code>X-Original-URL</code></li> <li>Using alternative HTTP methods (e.g. <code>GET</code> instead of <code>POST</code>) to execute unauthorized actions</li> </ul> <h4 class="wp-block-heading">Circumventing URL-based access restrictions</h4> <p>Applications may inconsistently enforce case sensitivity or path variations during access control checks, opening up security gaps. For example, an application may restrict access to an exact URL like:</p> <pre class="wp-block-code"><code>/admin/deleteUser</code></pre> <p>However, if access control rules do not account for variations and wildcards and do not match server settings for routing, an attacker may bypass restrictions using tricks like:</p> <pre class="wp-block-code"><code>/ADMIN/DELETEUSER /admin/deleteUser.anything /admin/deleteUser/</code></pre> <p>Framework-specific misconfigurations (such as <code>useSuffixPatternMatch</code> in Spring-based applications) can further increase attack surfaces.</p> <h3 class="wp-block-heading">Horizontal privilege escalation to access other users’ data</h3> <h4 class="wp-block-heading">User ID manipulation</h4> <p>Horizontal privilege escalation occurs when a user gains access to another user’s resources instead of their own. Consider an application where users can view their profile using:</p> <pre class="wp-block-code"><code>https:&#047;&#047;insecure-website.com/myaccount?id=123</code></pre> <p>An attacker may modify the id parameter to another user’s ID:</p> <pre class="wp-block-code"><code>https:&#047;&#047;insecure-website.com/myaccount?id=456</code></pre> <p>If the application does not validate ownership, the attacker accesses someone else’s data. This is a classic insecure direct object reference (IDOR) vulnerability.</p> <h4 class="wp-block-heading">Obfuscated user identifiers</h4> <p>Some applications attempt to mitigate IDOR attacks by using randomized or hashed user identifiers (e.g. GUIDs). While this makes brute-force attacks harder, these identifiers can still leak in other areas, such as:</p> <ul class="wp-block-list"> <li>User messages</li> <li>Public API responses</li> <li>System logs</li> </ul> <p>If an attacker can collect valid user identifiers from these or other sources, they could still execute IDOR-based privilege escalation.</p> <h3 class="wp-block-heading">Combining horizontal and vertical privilege escalation</h3> <p>An attacker can escalate from horizontal to vertical privilege escalation by compromising a privileged user account. For example, say an application accepts password reset requests based on a simple query parameter:</p> <pre class="wp-block-code"><code>https:&#047;&#047;insecure-website.com/reset-password?id=789</code></pre> <p>If an attacker can modify the id parameter to an admin user’s ID and the request is not verified further, they could reset the admin password and gain full system control.</p> <h3 class="wp-block-heading">Access control weaknesses in multi-step processes</h3> <p>Business applications often implement multi-step workflows, such as user account modifications or payment processes. If some steps enforce access control while others do not, attackers can skip the controlled steps and directly invoke privileged actions.</p> <p>For example:</p> <ol class="wp-block-list"> <li>Step 1 (properly protected): Load the account modification form&nbsp;</li> <li>Step 2 (properly protected): Submit changes&nbsp;</li> <li>Step 3 (not properly protected): Confirm changes</li> </ol> <p>If step 3 includes the results of previous steps and an attacker is able to skip steps 1 and 2 and directly submit a forged request to step 3, they will be able to bypass security controls.</p> <h3 class="wp-block-heading">Referrer-based access control flaws</h3> <p>Some applications rely on the <code>Referer</code> header to determine access. For example, an application might use the <code>Referer</code> header to enforce access control for users coming to <code>/admin</code> from a different page but allow access to operations such as <code>/admin/deleteUser</code> if the user is already coming from <code>/admin</code>.</p> <p>Since attackers can often manipulate headers, a forged request with a <code>Referer</code> header that says <code>/admin</code> may let them bypass such access restrictions.</p> <h3 class="wp-block-heading">Location-based access control bypass</h3> <p>Some applications restrict access based on the user’s geographical location (especially common for financial services and media streaming). However, attackers can circumvent these controls using:</p> <ul class="wp-block-list"> <li>VPNs or proxy servers to spoof locations.</li> <li>Client-side geolocation tampering by modifying browser settings.</li> <li>Manipulating HTTP request headers to fake their origin.</li> </ul> <p>Without server-side verification and multi-factor authentication, location-based restrictions can be easily bypassed.</p> <h2 class="wp-block-heading"><strong>Real-world examples of data breaches caused by broken access control&nbsp;</strong></h2> <p>Real-world attacks involving broken access control highlight the severity of this class of weaknesses:</p> <ul class="wp-block-list"> <li>Facebook (2013): A researcher discovered a vulnerability that allowed any user to delete photos from any account without permission, exposing a critical flaw in Facebook’s access control policies.</li> <li>Instagram (2019): An IDOR vulnerability enabled attackers to view private posts and stories by manipulating user IDs in API requests.</li> <li>GitHub (2022): A privilege escalation bug allowed users to gain higher access levels within repositories without authorization.</li> <li><a href="https://www.invicti.com/blog/web-security/idor-everywhere-dangers-of-direct-object-references/">Optus (2023)</a>: IDOR allowed a malicious hacker to directly access and enumerate nearly 10 million telco customer records.</li> </ul> <h2 class="wp-block-heading"><strong>How to prevent broken access control vulnerabilities</strong></h2> <p>Because broken access control is such a broad category of security risks, there is no single remedy for all possible access control flaws. The only way to mitigate the associated risks is to deeply integrate and enforce access-related security controls alongside secure application design principles that include access control as a fundamental aspect of design.</p> <h3 class="wp-block-heading"><strong>Follow the Principle of Least Privilege (PoLP)</strong></h3> <p>The Principle of Least Privilege ensures that users and systems only have the minimum necessary access required to perform their functions. This helps reduce the attack surface and limits potential damage from compromised accounts by restricting escalation options.</p> <h3 class="wp-block-heading"><strong>Use secure session management and authentication</strong></h3> <ul class="wp-block-list"> <li>Implement multi-factor authentication (MFA) to enhance identity verification.</li> <li>Use secure session tokens and proper timeout settings to prevent session hijacking.</li> <li>Enforce strong password policies and implement CAPTCHA mechanisms to prevent brute-force attacks.</li> </ul> <h3 class="wp-block-heading"><strong>Perform regular access control audits and reviews</strong></h3> <p>Regularly reviewing and auditing access control policies helps identify misconfigurations and unauthorized privilege escalations. Security teams should:</p> <ul class="wp-block-list"> <li>Conduct automated access control testing.</li> <li>Perform role-based access control (RBAC) audits.</li> <li>Review log files and access control events for suspicious activity.</li> </ul> <h3 class="wp-block-heading"><strong>Enforce proper error handling and logging</strong></h3> <ul class="wp-block-list"> <li>Avoid revealing excessive or sensitive information in error messages—a message like “Access Denied” gives an attacker much less useful information than “Invalid User ID.”</li> <li>Implement secure logging to track access control violations and potential attacks.</li> <li>Use intrusion detection systems (IDS) to monitor access attempts and anomalies.</li> </ul> <h3 class="wp-block-heading">Make access control a secure design consideration</h3> <p>Only adding access control as an afterthought at a later stage of development greatly increases the risk of broken access control vulnerabilities in production. To prevent this, standardize and follow secure design practices:</p> <ul class="wp-block-list"> <li>Define access control requirements during architecture and threat modeling.</li> <li>Use centralized, server-side enforcement for all permission checks.</li> <li>Design with role-based access and least privilege as defaults.</li> </ul> <h3 class="wp-block-heading">Continuously test for access control vulnerabilities in development and production with a DAST-first approach</h3> <p>Access control vulnerabilities—such as directory traversal, cross-site request forgery (CSRF), and insecure direct object references (IDOR)—are among the most common and dangerous issues in modern web applications. These flaws often arise from subtle implementation oversights that only surface during real-world usage. A DAST-first approach continuously scans running applications during development and in production, giving security teams visibility into actual exploit paths. Unlike tools that rely on code analysis, DAST works by interacting with live applications just as an attacker would, surfacing runtime issues that truly increase business risk.</p> <p>Where static application security testing (SAST) can generate long lists of theoretical vulnerabilities without clear exploitability, dynamic testing through DAST focuses on what can actually be attacked. This not only cuts through the noise of false positives but also enables faster, more confident remediation. Invicti’s proof-based scanning takes this further by automatically confirming vulnerabilities with safe proof-of-exploit, eliminating guesswork for developers and freeing up security resources. With DAST-first, organizations can move beyond finding “everything” to fixing what matters—reducing real-world risk without slowing down development.</p> <h2 class="wp-block-heading">Conclusion</h2> <p>The OWASP Top 10 lists broken access control as the #1 application security risk category for a very good reason: access control is the foundation of all cybersecurity. Attackers want to get access to your data and systems by any means possible, and access control failures simply leave the door open for them. By enforcing strict access policies, implementing least privilege principles, and performing regular vulnerability scanning alongside formal audits, businesses can minimize exposure to unauthorized access and protect their sensitive assets with a DAST-first approach.</p> <p><a href="https://www.invicti.com/get-demo/">Get a proof-of-concept demo to see DAST-first AppSec in action!</a></p> <p></p> <h2 class="wp-block-heading">Frequently asked questions about broken access control</h2> <div class="invicti-block accordion style-one" id="accordion_67ef8d8db2fa5"> <div class="accordion-section"> <h4 class="accordion-heading">What is broken access control?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Broken access control vulnerabilities are security flaws where applications fail to enforce access policies correctly, allowing unauthorized users to access restricted resources or perform privileged actions.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">What are the types of access control?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>The main types of access control are:</p> <ul> <li>Discretionary Access Control (DAC): The owner of the resource determines access permissions. <li>Mandatory Access Control (MAC): Access permissions are enforced by a central authority based on security classifications. <li>Role-Based Access Control (RBAC): Access is granted based on the user’s role within the organization. <li>Attribute-Based Access Control (ABAC): Access decisions are based on a combination of attributes such as user roles, resource types, actions, time of day, or location.</ul> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">What are the issues in access control?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Common security issues related to access control include:</p> <ul> <li>Misconfigured permissions that grant excessive privileges. <li>Lack of proper role enforcement leading to privilege escalation. <li>Exposing sensitive URLs that attackers can manipulate. <li>Weak session management that allows unauthorized access through session hijacking.</ul> </div> </div> </div> </div> <p>The post <a href="https://www.invicti.com/blog/web-security/broken-access-control/">Broken access control: The leading OWASP Top 10 security risk</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Next.js middleware authorization bypass vulnerability: Are you vulnerable?</title> <link>https://www.invicti.com/blog/security-labs/next-js-middleware-bypass-vulnerability/</link> <dc:creator><![CDATA[Dan Murphy]]></dc:creator> <pubDate>Tue, 25 Mar 2025 13:56:28 +0000</pubDate> <category><![CDATA[Security Labs]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=103154</guid> <description><![CDATA[<p>A critical vulnerability in the Next.js framework, officially disclosed on March 21, 2025, allows attackers to bypass middleware security controls through a simple header manipulation. This post summarizes what we know about CVE-2025-29927, how you can mitigate the vulnerability, and how Invicti can help you detect and confirm your organization’s risk.</p> <p>The post <a href="https://www.invicti.com/blog/security-labs/next-js-middleware-bypass-vulnerability/">Next.js middleware authorization bypass vulnerability: Are you vulnerable?</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p></p> <blockquote class="wp-block-quote is-style-default is-layout-flow wp-block-quote-is-layout-flow"> <p><strong><em>What you need to know</em></strong></p> <p>&nbsp;</p> <ul class="wp-block-list"> <li>A remote authorization bypass vulnerability identified as <a href="https://nextjs.org/blog/cve-2025-29927">CVE-2025-29927</a> was confirmed in Next.js, one of the most popular React frameworks used to build web applications.</li> <li>The vulnerability allows attackers to completely bypass Next.js functionality in an application, including commonly used critical security functions such as authentication and authorization.</li> <li>As of March 25, 2025, all Invicti products can identify and report the CVE.</li> <li>The vulnerability affects the following Next.js versions: <ul class="wp-block-list"> <li>Next.js 11.1.4 through 13.5.6 (unpatched)</li> <li>Next.js 14.x before 14.2.25</li> <li>Next.js 15.x before 15.2.3</li> </ul> </li> <li>Upgrading to a non-vulnerable version is the only guaranteed fix. Proxy-level WAF blocking may work temporarily but is not recommended in the long run.</li> </ul> </blockquote> <h2 class="wp-block-heading"><strong>Understand your Next.js middleware bypass risk</strong></h2> <p>The vulnerability allows attackers to completely bypass the middleware functionality by including a specially crafted <code>x-middleware-subrequest</code> header in their requests. Middleware can best be thought of as a processing chain that lets software modules inspect, modify, or reroute an HTTP request before it reaches its final code handler. It is a natural place to implement cross-cutting concerns like authentication—a very common pattern is having a middleware implement that logic that expresses “redirect to <code>/login</code> if there is not a valid authentication cookie”.</p> <p>This vulnerability is particularly concerning because Next.js middleware is commonly used for critical security functions such as authentication, authorization, path rewriting, and implementing security headers, all of which can be trivially bypassed by an attacker.</p> <p>To get an idea of how bad this can be, imagine an airport security checkpoint where security agents (the middleware) carefully check everyone’s ID and boarding pass before letting them proceed to the gate. Now, suppose there’s a secret phrase that, when whispered to any security agent, causes them to immediately wave you through without checking anything. That’s essentially what the Next.js middleware authorization bypass vulnerability allows: using a special HTTP header to completely bypass security checks that would normally protect sensitive routes and resources.</p> <h2 class="wp-block-heading"><strong>Are you vulnerable to the Next.js middleware bypass?</strong></h2> <p>If your answer to BOTH of the following questions is “yes”, <strong><em>your application is vulnerable unless patched</em></strong>:</p> <ul class="wp-block-list"> <li>Do you rely on Next.js middleware for security controls?</li> <li>Are you running a self-hosted Next.js application using <code>next start</code> with <code>output: 'standalone'</code>?</li> </ul> <p>Applications are particularly at risk if:</p> <ul class="wp-block-list"> <li>You use middleware for authentication or authorization checks</li> <li>You rely on middleware for implementing security headers like Content Security Policy (CSP), used to define limitations on where resources are permitted to be loaded</li> <li>You use middleware for path rewriting to restrict access to certain routes</li> </ul> <p>Applications hosted on Vercel or Netlify are <em>not affected</em>, as these platforms have implemented mitigations at their edge layers. Applications deployed as static exports (where middleware is not executed) are also <em>not affected</em>.</p> <p>If you don’t know the details of your Next.js usage or want the ability to assess it independently, running an automated DAST tool to confirm your vulnerability is a great place to start.</p> <h2 class="wp-block-heading"><strong>How the Next.js middleware vulnerability works</strong></h2> <p>Next.js middleware uses an internal header called <code>x-middleware-subrequest</code> to prevent recursive requests from triggering infinite loops. The security vulnerability allows an attacker to manipulate this header to trick the Next.js application into skipping middleware execution entirely.</p> <p>For different versions of Next.js, the exploit works slightly differently:</p> <ul class="wp-block-list"> <li>For older versions (pre-12.2): <br><code>x-middleware-subrequest: pages/_middleware</code></li> <li>For modern versions:<br><code>x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware</code><br>(or <code>src/middleware:src/middleware:src/middleware:src/middleware:src/middleware</code> if using the <code>src</code> directory)</li> </ul> <p>When this header is present with the appropriate value, the middleware is completely bypassed, allowing the request to reach its original destination without any security checks or modifications that would have been applied by the middleware.</p> <h2 class="wp-block-heading"><strong>How Invicti DAST products detect CVE-2025-29927</strong></h2> <h3 class="wp-block-heading"><strong>Passive detection through traffic analysis with dynamic SCA (Invicti)</strong></h3> <p>The vulnerability is detected through passive monitoring of web traffic during a security scan without making active requests. Invicti Enterprise uses this technique with its <a href="https://www.invicti.com/support/how-invicti-identifies-outofdate/">vulnerability database</a> to detect the flaw. This technique looks for the <code>x-powered-by: Next.js</code> header in responses, which confirms the application is using Next.js. The presence of the vulnerable version is further confirmed by evaluating the <code>next.version</code> function in the browser’s JavaScript context to extract the precise version</p> <p>We then compare this value to our continuously updated database of known CVEs and network detection signatures to determine if an insecure version of Next.js has been encountered.</p> <p>As of Tuesday, March 25, 2025, this check is live for all Invicti Enterprise, Invicti Standard, and Acunetix 360 customers.&nbsp;</p> <h3 class="wp-block-heading"><strong>Active detection logic (Acunetix)</strong></h3> <p>Invicti’s security research team has developed a check for the Acunetix engine to detect if your applications are vulnerable to CVE-2025-29927. As of Monday, March 24, 2025, this check is live for all Acunetix Premium customers.</p> <p>Here’s how the active check works step by step:</p> <ol class="wp-block-list"> <li><strong>Identify Next.js middleware usage</strong>: The check first looks for the telltale signs of Next.js middleware, specifically a 307 redirect where the response body equals the location header value. This pattern is unique to Next.js middleware redirects.</li> <li><strong>Verify Next.js framework presence</strong>: Confirm the application is using Next.js by checking for the <code>x-powered-by: Next.js</code> header in responses.</li> <li><strong>Test with bypass payloads</strong>: The detection mechanism tries different bypass payloads based on the potential Next.js version: <ul class="wp-block-list"> <li>For newer versions (13.2.0+): <code>middleware:middleware:middleware:middleware:middleware</code> (and the <code>src</code> variant)</li> <li>For older versions (pre-12.2): <code>pages/_middleware</code></li> <li>For intermediate versions (12.2 to 13.2.0): <code>middleware</code></li> </ul> </li> <li><strong>Validation through contrast</strong>: To avoid false positives, the test performs multiple validation checks: <ul class="wp-block-list"> <li>Send a request with the potential bypass header and check if it returns a 200 OK.</li> <li>Send a control request with a slightly modified header, such as <code>Y-Middleware-Subrequest</code>, to confirm it still redirects (307).</li> <li>Send another request with an invalid value to confirm proper behavior.</li> <li>Repeat the successful bypass to ensure consistency.</li> </ul> </li> <li><strong>Confirm vulnerability</strong>: Only after all validation steps pass is the vulnerability confirmed, reducing the risk of false positives.</li> </ol> <h2 class="wp-block-heading"><strong>Mitigation steps for CVE-2025-29927</strong></h2> <ol class="wp-block-list"> <li>Update immediately: <ul class="wp-block-list"> <li>For Next.js 15.x: Update to ≥ 15.2.3</li> <li>For Next.js 14.x: Update to ≥ 14.2.25</li> <li>For Next.js 13.x: Update to ≥ 13.5.9</li> <li>For Next.js 12.x: Update to ≥ 12.3.5</li> </ul> </li> <li>If updating isn’t possible immediately: <ul class="wp-block-list"> <li>Block the <code>x-middleware-subrequest</code> header at your edge/proxy level (<em>not</em> in middleware itself).</li> <li>Cloudflare users can enable a Managed WAF rule that blocks this attack. Be aware that Cloudflare has <a href="https://developers.cloudflare.com/changelog/2025-03-22-next-js-vulnerability-waf/">changed this WAF rule to be opt-in</a> after reports of 3rd party authentication frameworks being impacted. We suggest you focus on upgrading Next.js.</li> </ul> </li> </ol> <p>Invicti Security would like to acknowledge Rachid Allam and Yasser Allam for their original <a href="https://zhero-web-sec.github.io/research-and-things/nextjs-and-the-corrupt-middleware" target="_blank" rel="noreferrer noopener nofollow">research and writeup</a> of their findings, as well as our internal teams that worked to turn out a check to customers within a single business day.</p> <p>Our security team is continuously monitoring this situation and will update as more information becomes available.</p> <h2 class="wp-block-heading">Final thought</h2> <p>There is an <a href="https://en.wikipedia.org/wiki/Bloody_Mary_(folklore)" target="_blank" rel="noreferrer noopener nofollow">urban legend</a> that used to circulate around schoolyards about summoning ghosts by chanting their names repeatedly in the dark in front of a mirror. Apparently, the name was wrong—instead of Bloody Mary, those kids just had to say “Middleware-y” five times in an HTTP header to summon a far scarier security bypass…</p> <p>The post <a href="https://www.invicti.com/blog/security-labs/next-js-middleware-bypass-vulnerability/">Next.js middleware authorization bypass vulnerability: Are you vulnerable?</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Vulnerable and outdated components: An OWASP Top 10 threat</title> <link>https://www.invicti.com/blog/web-security/vulnerable-and-outdated-components-owasp-top-10/</link> <dc:creator><![CDATA[Jesse Neubert]]></dc:creator> <pubDate>Tue, 25 Mar 2025 10:15:13 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[owasp-top-10]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=103148</guid> <description><![CDATA[<p>Dealing with vulnerable and outdated components is the number one risk in software supply-chain security. The challenges of maintaining a full component inventory and keeping up with constant feature updates and security patches require a more proactive approach built around dynamic testing to check what you’re running and which component vulnerabilities to prioritize.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/vulnerable-and-outdated-components-owasp-top-10/">Vulnerable and outdated components: An OWASP Top 10 threat</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p>Vulnerable and outdated components remain a persistent cybersecurity threat across modern software development. As part of the <a href="https://www.invicti.com/blog/web-security/what-owasp-top-ten-2021-categories-mean/">OWASP Top 10</a>, this category (classified as A06:2021) highlights the dangers of using components with known security vulnerabilities or those that are no longer supported. Without proper management, these weak links can be the entry point for serious attacks on your web applications.</p> <p>Let’s break down what makes this supply-chain security risk so critical—and how to defend against it with an approach that combines proper inventory management with dynamic security testing to focus priority components with real, exploitable vulnerabilities.</p> <h2 class="wp-block-heading">What are vulnerable and outdated components?</h2> <p>Vulnerable and outdated components refer to third-party libraries, frameworks, or software dependencies that have known security flaws and/or are no longer maintained. These components often include:</p> <ul class="wp-block-list"> <li>Open-source libraries</li> <li>Backend frameworks</li> <li>Client-side JavaScript packages</li> <li>Server plugins and middleware</li> </ul> <p>In many cases, third-party components are integrated into applications without ongoing monitoring across the entire software lifecycle, potentially leaving them exposed to exploits long after patches are released.</p> <h2 class="wp-block-heading">Examples of vulnerable and outdated components</h2> <p>A common example involves outdated versions of Apache Struts. In 2017, an unpatched vulnerability in Apache Struts was exploited in a major data breach that impacted millions. Despite the availability of updates, many organizations continued using the flawed version, unaware of the risk or unable to update due to compatibility issues.</p> <p>Other examples include:</p> <ul class="wp-block-list"> <li>Running a version of Log4j vulnerable to remote code execution (RCE) via <a href="https://www.invicti.com/blog/web-security/is-log4shell-worst-software-vulnerability-ever/">Log4Shell</a></li> <li>Using an outdated version of jQuery with known <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">cross-site scripting (XSS)</a> flaws</li> <li>Keeping legacy plugins in content management systems like WordPress or Drupal</li> <li>Using unpatched database drivers or authentication modules</li> </ul> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <p>Apart from having security vulnerabilities, third-party components can also be dangerous in other ways. <a href="https://www.invicti.com/blog/web-security/polyfill-supply-chain-attack-when-your-cdn-goes-evil/">Read</a> and <a href="https://www.invicti.com/podcasts/appsec-serialized-1x4-another-code-brick-in-the-wall/">listen</a> about the Polyfill library crisis where a new project owner started including malicious code in an established package used by thousands of sites.</p> </blockquote> <h2 class="wp-block-heading">Why protecting against vulnerable and outdated components matters</h2> <p>There are many valid reasons to continue using an older version of a software library or other component. New versions require testing before and after deployment to make sure they don’t break existing functionality, so sticking with an older version for some time may be a practical necessity. Problems begin when the old version has a known vulnerability that increases your attack surface.&nbsp;</p> <h3 class="wp-block-heading">Risks of using vulnerable and outdated components</h3> <p>Neglecting these components introduces several security and operational risks:</p> <ul class="wp-block-list"> <li><strong>Known exploitability</strong>: Attackers actively scan for versions of popular libraries with known CVEs.</li> <li><strong>Automated attacks</strong>: Vulnerable components are often targeted by bots, increasing exposure.</li> <li><strong>Unauthorized access</strong>: An auth bypass vulnerability in an application component could entirely negate access control, exposing sensitive data and allowing escalation.</li> <li><strong>Legal and compliance issues</strong>: Failing to patch known vulnerabilities may violate compliance standards like PCI DSS or HIPAA.</li> <li><strong>Cascading failures</strong>: A flaw in a third-party library can affect multiple parts of your application stack.</li> <li><strong>Data integrity failures</strong>: Component vulnerabilities may enable attackers to introduce malicious code into a component to maintain a persistent presence.</li> </ul> <p>By prioritizing the identification and remediation of these components, organizations can reduce the likelihood of being breached through known attack vectors.</p> <h2 class="wp-block-heading">How can you protect against vulnerable and outdated components?</h2> <p>The key to protection is proactive management—knowing what’s in your application, monitoring for vulnerabilities, and acting on verified threats.</p> <h3 class="wp-block-heading">Best practices for managing vulnerable and outdated components</h3> <ol class="wp-block-list"> <li><strong>Inventory all software components</strong>: Maintain a complete and updated software bill of materials (SBOM) to track all dependencies.</li> <li><strong>Use tools that verify real risk</strong>: Static tools like <a href="https://www.invicti.com/learn/software-composition-analysis-sca/">software composition analysis (SCA)</a> can flag outdated components, but they often flood teams with alerts. A DAST-first approach focuses on what&#8217;s actually exploitable, helping teams prioritize.</li> <li><strong>Automate updates</strong>: Where possible, use dependency management tools to automate updates and security patches.</li> <li><strong>Apply virtual patching</strong>: Use web application firewalls (WAFs) as a stop-gap while updates are applied.</li> <li><strong>Integrate security into CI/CD</strong>: Embed security checks into the development pipeline to catch issues early.</li> </ol> <h3 class="wp-block-heading">Securing your applications</h3> <p>Finding and patching every single outdated component isn’t always realistic—but fixing the ones that matter is. That’s why organizations benefit from combining SCA with <a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/">dynamic application security testing (DAST)</a>. While static SCA helps identify outdated components in your code, DAST (and its own dynamic SCA) shows you what components you’re running and whether they have vulnerabilities that are actually exploitable in your live environment.</p> <p>A DAST-first approach cuts through the noise by validating component vulnerabilities and showing which of them malicious hackers could use. This not only accelerates triage and remediation but also helps security and development teams stay focused on real risk, not false positives or theoretical alerts.</p> <h2 class="wp-block-heading">How a DAST-first approach helps manage vulnerable and outdated components</h2> <p>Most organizations rely on static SCA tools to identify outdated or risky components. While static SCA plays a vital role in visibility, it often generates an overwhelming number of alerts—many of which may not be actionable in a real-world context. This creates alert fatigue, delays remediation, and can distract teams from addressing critical issues.</p> <p>A DAST-first approach flips this model by focusing on actual exploitable vulnerabilities in running applications. Rather than flagging every outdated library present on the server side or your code repository, DAST identifies vulnerable components based on fingerprinting and observed runtime behavior during scanning.</p> <p>Here’s how a DAST-first strategy adds value:</p> <ul class="wp-block-list"> <li><strong>Focus on what’s exploitable</strong>: DAST evaluates live applications and APIs, identifying components that are actively used, vulnerable, and exploitable, not just out of date.</li> <li><strong>Proof-based validation</strong>: Tools like Invicti provide automatic proof-of-exploit for common vulnerabilities to confirm that an outdated component poses real risk before escalating it to the development team.</li> <li><strong>Faster triage and fewer false positives</strong>: Validated findings enable security teams to prioritize the components that need their attention most, accelerating risk reduction and minimizing wasted effort on evaluating non-issues.</li> <li><strong>Actionable insights for developers</strong>: Developers receive concrete, reproducible details about vulnerabilities in specific components, speeding up decision-making and mitigation.</li> </ul> <p>When used alongside static SCA, a DAST-first approach ensures that you’re not just reacting to aging software but actively securing your applications against the real-world threats those components can introduce. It’s the fastest, most efficient way to reduce risk and protect your application stack from vulnerabilities that matter. And while static SCA only addresses software component security, DAST also covers vulnerabilities in first-party code, APIs, and dynamic dependencies, as well as security misconfigurations and more.</p> <h2 class="wp-block-heading">Conclusion</h2> <p>Running vulnerable or outdated components is a constant risk with complex modern software, but they don’t have to be your Achilles’ heel. By knowing what’s in your stack and using security tools that validate real-world risk, you can drastically reduce your exposure.</p> <p>Combining SBOMs and a robust patch management process with continuous discovery and dynamic security testing through a DAST-first approach is the most effective way to stay secure without slowing down development.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/vulnerable-and-outdated-components-owasp-top-10/">Vulnerable and outdated components: An OWASP Top 10 threat</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Missing X-Frame-Options header? You should be using CSP anyway</title> <link>https://www.invicti.com/blog/web-security/missing-x-frame-options-header/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Fri, 07 Mar 2025 11:25:34 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[security-headers]]></category> <category><![CDATA[http-security-headers]]></category> <category><![CDATA[clickjacking]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=102567</guid> <description><![CDATA[<p>When clickjacking attacks using iframes first became possible, browser vendors reacted by adding <code>X-Frame-Options</code> as a dedicated security header for controlling page embedding permissions. Learn how setting the right Content Security Policy makes up for a missing <code>X-Frame-Options</code> header today.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/missing-x-frame-options-header/">Missing X-Frame-Options header? You should be using CSP anyway</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow"> <p><strong>Key takeaways</strong></p> <p>&nbsp;</p> <ul class="wp-block-list"> <li><code>X-Frame-Options</code> (XFO) is an obsolete HTTP security header originally intended to protect against clickjacking attacks.</li> <li>In the past, a missing <code>X-Frame-Options</code> header put users at risk by allowing attackers to embed a site or web application within their malicious site.</li> <li>The <code>X-Frame-Options</code> header always had several limitations and is no longer the recommended way to control frame embedding permissions.</li> <li>Use the <code>frame-ancestors</code> directive in your Content Security Policy (CSP) header to replace <code>X-Frame-Options</code>.</li> </ul> </blockquote> <h2 class="wp-block-heading"><strong>Why was the X-Frame-Options header introduced?</strong></h2> <p>The <code>X-Frame-Options</code> header was introduced by Microsoft with Internet Explorer 8 specifically as a means of preventing clickjacking attacks. Support for the header was quickly added by other web browsers since, at the time, <code>X-Frame-Options</code> was the only easy way to tell the browser whether a page should be allowed to render in an iframe.</p> <p>Being more of a quick fix than a comprehensive solution, <code>X-Frame-Options</code> provided only two universally supported parameters:</p> <ul class="wp-block-list"> <li>To prevent the current page from being embedded in any iframe, you would set <code>X-Frame-Options: DENY</code></li> <li>To allow embedding but only for requests originating from the same domain, you would set <code>X-Frame-Options: SAMEORIGIN</code></li> </ul> <p>A third parameter, <code>ALLOW-FROM <em>URI</em></code>, would in theory let you allow embedding from a specific named origin, but in practice this had inconsistent browser support and could cause the entire header to be ignored, negating any protection. Unlike some other headers, <code>X-Frame-Options</code> had to be set in the web server config file, so putting it in an HTML meta tag like <code>&lt;meta http-equiv="X-Frame-Options" content="deny"&gt;</code> would have no effect.</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <h2 class="wp-block-heading"><strong>Clickjacking attacks 101</strong></h2> <p>Clickjacking is a UI redressing attack where malicious actors use tricks like iframe embedding, scripting, CSS styling, and transparency manipulation to fool the user into performing unintended actions on a page. Victims believe they are clicking on a visible element when, in reality, they are interacting with a hidden element from a different page loaded into an iframe. This technique can be used to hijack login credentials, bypass authentication, authorize unwanted transactions, or trick users into downloading malware.</p> <p><a href="https://www.invicti.com/learn/clickjacking/">Learn more about clickjacking attacks</a></p> </blockquote> <h2 class="wp-block-heading"><strong>Why was X-Frame-Options deprecated if it was so useful?</strong></h2> <p>While effective for basic use cases, <code>X-Frame-Options</code> was more of a blunt instrument than a serious security tool. As site structures and configurations got vastly more complex, it became clear that the header was not a practical solution. <code>X-Frame-Options</code> limitations included:</p> <ul class="wp-block-list"> <li><strong>Lack of granular control</strong>: Your only options were to block all embedding or allow embedding within the same origin.</li> <li><strong>Per-page settings only</strong>: You had to set the header separately for every web page, with no way to specify more general behavior at site or domain level.</li> <li><strong>No reporting or testing mode</strong>: There was no way to test a setting without immediately enforcing it immediately, leading to potential usability and maintenance issues.</li> <li><strong>Inconsistent browser support</strong>: The <code>ALLOW-FROM</code> directive that would give at least a little more flexibility was never universally supported by all major browsers and was quickly deprecated.</li> </ul> <p>Even though modern browsers still support the two basic <code>X-Frame-Options</code> directives, the current best practice for clickjacking protection is to use the <code>frame-ancestors</code> directive in your CSP header instead.</p> <h2 class="wp-block-heading"><strong>How to use CSP to replace X-Frame-Options</strong></h2> <p>Including the <code>frame-ancestors</code> directive in your <a href="https://www.invicti.com/blog/web-security/content-security-policy/">Content Security Policy</a> header gives you all the capabilities of <code>X-Frame-Options</code> while eliminating its disadvantages and greatly increasing flexibility:</p> <ul class="wp-block-list"> <li><strong>Fine-grained control</strong>: The ability to list any number of URLs that are allowed to embed your page (including wildcards) gives you full control while also easing maintenance. </li> <li><strong>Universal and standardized support</strong>: CSP is a recognized and recommended standard for controlling content sources and behaviors.</li> <li><strong>Easier security policy management</strong>: Making the frame embedding policy a part of your broader content policy makes it far easier to manage multiple sites and domains. </li> <li><strong>Report-only header for testing</strong>: The additional <code>Content-Security-Policy-Report-Only</code> header lets you test new or changed CSP directives without applying them to the page or disabling existing directives.</li> </ul> <p>Moreover, most modern sites and web apps apply some kind of CSP anyway, primarily to protect against <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">cross-site scripting (XSS)</a>, so including frame embedding policies there makes more sense than using a separate header.</p> <h3 class="wp-block-heading">Examples of using frame-ancestors to replace X-Frame-Options</h3> <p>To use <code>frame-ancestors</code> as a drop-in replacement for blocking with <code>X-Frame-Options: DENY</code>, set the following header (note that a real CSP header will also include many other directives and can get very long, so these examples focus only on <code>frame-ancestors</code>):</p> <pre class="wp-block-code"><code>Content-Security-Policy: frame-ancestors 'none';</code></pre> <p>To directly replace <code>X-Frame-Options: SAMEORIGIN</code>, use:</p> <pre class="wp-block-code"><code>Content-Security-Policy: frame-ancestors 'self';</code></pre> <p>More typical usage is to specify multiple trusted sources alongside the current origin, including subdomains if needed:</p> <pre class="wp-block-code"><code>Content-Security-Policy: frame-ancestors 'self' example.com *.example.com;</code></pre> <p>This approach offers more flexible control, universal browser support, easier maintenance, and a more comprehensive approach to security compared to <code>X-Frame-Options</code>.</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <p>The <code>frame-ancestors</code> directive in your CSP should not be confused with <code>frame-src</code>. While <code>frame-ancestors</code> controls where the current page may be embedded, <code>frame-src</code> tells the browser what content sources are permitted for frames used on the page. The two directives can be combined.</p> </blockquote> <h2 class="wp-block-heading"><strong>Why am I still seeing “Missing X-Frame-Options header”?</strong></h2> <p>If you’re seeing warnings about a missing XFO header, it’s likely they are coming from an older security tool or some legacy configuration. Before CSP became the norm, many security scanners (including Invicti products) flagged a missing <code>X-Frame-Options</code> header as a low-severity vulnerability or informational-level warning because it could mean the site wasn’t protecting its users from clickjacking attempts.</p> <p>With the evolution of browser security and the widespread adoption of CSP, setting XFO headers is no longer a best practice. This is why modern application security tools have moved away from recommending <code>X-Frame-Options</code> and flagging its omission, even though any existing XFO headers will continue to work (at least for <code>DENY</code> and <code>SAMEORIGIN</code> directives). Instead, up-to-date vulnerability scanners should advise you to use the CSP <code>frame-ancestors</code> directive, which provides more functionality and is more flexible.</p> <h3 class="wp-block-heading"><strong>Missing X-Frame-Options header example</strong></h3> <p>To illustrate, here is how older versions of Invicti DAST tools used to warn about a missing XFO header:</p> <pre class="wp-block-code"><code>Invicti detected a missing X-Frame-Options header, which means that this website could be at risk of a clickjacking attack. The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a frame or an iframe. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, ensuring that their content is not embedded into other pages or frames.</code></pre> <p>If your security scanner still reports XFO as a recommended header, it could mean that you need to update it or look for a tool that keeps up with modern best practices.</p> <h2 class="wp-block-heading"><strong>Final thoughts: Keeping up with improving defensive technologies</strong></h2> <p>In the younger and less standardized years of web security, adding a custom security header was often the quickest way to protect users against a new type of attack. With more official recommendations and standards moving at a glacial pace, it was mostly up to major browser vendors to coordinate security header specifications and implementations, often leading to inconsistent browser support and maintenance headaches for website owners.</p> <p>Today, web technologies are far more mature and standardized, as is web development overall, making it possible to move away from point solutions like <code>X-Frame-Options</code> and towards more holistic protection with CSP. Instead of using a dedicated header just to prevent clickjacking, you can make clickjacking protection one part of a carefully designed content security policy. Staying up to date with best practices and scanning regularly using proven <a href="https://www.invicti.com/blog/web-security/how-to-choose-right-application-security-tools/">AppSec tools</a> will help keep your websites, applications, and APIs secure from common attacks across your entire attack surface.</p> <h2 class="wp-block-heading"><strong>Frequently asked questions about missing X-Frame-Options headers</strong></h2> <div class="invicti-block accordion style-one" id="accordion_67ef8d8dbde07"> <div class="accordion-section"> <h4 class="accordion-heading">What is “X-Frame-Options Header Not Set”?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>This warning means a security tool has detected that your website or application is not setting the <code>X-Frame-Options</code> HTTP header to prevent clickjacking. However, sending this header is no longer considered a best practice, and you should instead use the <code>frame-ancestors</code> directive in CSP.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">What is the difference between missing X-Content-Type-Options and X-Frame-Options headers?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p><code>X-Frame-Options</code> was used to prevent clickjacking by controlling iframe embedding and is obsolete, whereas <code>X-Content-Type-Options</code> prevents MIME type sniffing attacks by enforcing declared content types and setting it to <code>nosniff</code> is still recommended.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">How do I enable X-Frame-Options?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Although the <code>X-Frame-Options</code> header is still supported by browsers and you can set it to <code>DENY</code> to block all embedding or <code>SAMEORIGIN</code> to allow embedding within the same origin, the recommended practice is now to use the <code>frame-ancestors</code> directive in CSP for broader support and more precise control.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">How do you check the X-Frame-Options header in Chrome?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>You can directly check response headers using dev tools in your browser. Open dev tools (usually F12), go to the Network tab, reload the page, select the loaded page in dev tools, and inspect the Headers tab to see HTTP response headers such as <code>X-Frame-Options</code> or <code>Content-Security-Policy</code>.</p> </div> </div> </div> </div> <p>The post <a href="https://www.invicti.com/blog/web-security/missing-x-frame-options-header/">Missing X-Frame-Options header? You should be using CSP anyway</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Missing HTTP security headers: Avoidable risk, easy fix</title> <link>https://www.invicti.com/blog/web-security/missing-http-security-headers/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Thu, 20 Feb 2025 17:30:00 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[http-security-headers]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=102490</guid> <description><![CDATA[<p>Missing HTTP security headers can leave websites and applications exposed to a variety of attacks. If the browser fails to enforce security measures due to missing security headers, apps can be far more vulnerable to attacks like cross-site scripting and clickjacking, increasing the risk of unauthorized access, sensitive data exposure, and further exploitation by malicious actors.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/missing-http-security-headers/">Missing HTTP security headers: Avoidable risk, easy fix</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <h2 class="wp-block-heading">What are HTTP security headers?</h2> <p>HTTP security headers are a crucial part of web security, providing an additional layer of protection against common threats such as <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">cross-site scripting (XSS)</a>, <a href="https://www.invicti.com/learn/clickjacking/">clickjacking</a>, and content injection attacks. The term covers several different HTTP headers that instruct the browser how to behave safely when connecting to servers and handling site content. Using and correctly configuring the right headers can greatly enhance overall security by heading off entire classes of vulnerabilities.</p> <h2 class="wp-block-heading">Why are HTTP security headers important?</h2> <p>Security headers play a key role in defending web applications from attacks that exploit browser behavior. They can apply a variety of directives to ensure safe browsing across web pages, restrict access to subdomains, and manage referer policies to minimize data leakage. Among other things, headers can help modern browsers enforce <a href="https://www.invicti.com/learn/http-strict-transport-security-hsts/">HTTP Strict Transport Security (HSTS)</a>, control cross-origin requests (CORS), mitigate cross-site scripting attacks, and eliminate MIME type sniffing vulnerabilities. When properly defined and maintained, security headers are a vital part of implementing security policies to prevent unauthorized content from loading or restrict the execution of unexpected (and potentially malicious) scripts.</p> <h2 class="wp-block-heading">What is the risk of a missing HTTP security header?</h2> <p>When an HTTP security header is missing, an application may be more vulnerable to specific attack vectors. Here are some common risks associated with missing (or misconfigured) security headers:</p> <ul class="wp-block-list"> <li><strong>Missing Content Security Policy (CSP) header</strong>: Without CSP to block unexpected content sources, an application may allow attackers to inject and execute malicious scripts in users’ browsers to perform cross-site scripting (XSS).</li> <li><strong>Missing CSP or X-Frame-Options header</strong>: If iframe content sources are not constrained, attackers could execute clickjacking attacks by embedding your site within an iframe and tricking users into performing unintended actions.</li> <li><strong>Missing X-Content-Type-Options header</strong>: Permissive MIME sniffing settings can be abused to trick the browser into incorrectly interpreting content types, leading to data exposure vulnerabilities.</li> <li><strong>Missing Strict-Transport-Security (HSTS) header</strong>: If HTTPS is not enforced by both the browser and server, user sessions could be downgraded to unencrypted HTTP, risking man-in-the-middle attacks and data exposure.</li> <li><strong>Missing Referrer-Policy header</strong>: In certain situations, exposing referrer data can pose a security and privacy risk by revealing the URL of a previous referring page.</li> </ul> <h2 class="wp-block-heading">Which security headers should I use?</h2> <p>The examples below use a typical subset of possible HTTP security headers, but the specific headers you need will depend on your specific use case. Different applications have different security and policy requirements, and the appropriate headers will vary based on the technologies and frameworks in use. If you’re seeing a warning about missing security headers, it will usually also tell you which header is missing or misconfigured.</p> <p>As a general rule, HSTS and CSP are the two minimum must-have headers—one to enforce encryption and the other to cover the majority of content-related security requirements. For a detailed discussion of security headers, see our <a href="https://www.invicti.com/white-papers/whitepaper-http-security-headers/">white paper on security headers</a> and an in-depth blog post on why <a href="https://www.invicti.com/blog/web-security/http-security-headers/">HTTP headers are an easy way to harden your applications</a>.</p> <h2 class="wp-block-heading">How do I add HTTP security headers?</h2> <p>While HTTP headers can also be set at the application level, setting them on the server is the usual practice. Adding HTTP security headers depends on your web server and technology stack. Below are sample configuration file entries for common web servers, demonstrating some typical security header choices and values:</p> <h3 class="wp-block-heading">Apache</h3> <p>Edit the <code>.htaccess</code> or main configuration file:</p> <pre class="wp-block-code is-style-code-highlighter"><code>Header set X-Frame-Options "SAMEORIGIN" Header set X-Content-Type-Options "nosniff" Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'" Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"</code></pre> <h3 class="wp-block-heading">Nginx</h3> <p>Modify the server block in the <code>nginx.conf</code> file to improve security:</p> <pre class="wp-block-code is-style-code-highlighter language-nginx"><code>add_header X-Frame-Options "DENY"; add_header X-Content-Type-Options "nosniff"; add_header Content-Security-Policy "default-src 'self'"; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";</code></pre> <h3 class="wp-block-heading">IIS (Windows Server)</h3> <p>Edit the web.config file. Note that IIS may require a restart after modifying this file to apply changes, especially for older server versions.</p> <pre class="wp-block-code is-style-code-highlighter language-xml"><code>&lt;configuration&gt; &nbsp;&nbsp;&lt;system.webServer&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;httpProtocol&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;customHeaders&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;add name="X-Frame-Options" value="DENY" /&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;add name="X-Content-Type-Options" value="nosniff" /&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" /&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;add name="Content-Security-Policy" value="default-src 'self'" /&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/customHeaders&gt; &nbsp;&nbsp;&nbsp;&nbsp;&lt;/httpProtocol&gt; &nbsp;&nbsp;&lt;/system.webServer&gt; &lt;/configuration&gt;</code></pre> <h3 class="wp-block-heading">Node.js (Express)</h3> <p>As an example of adding security headers in the application, you can use the Helmet middleware to automatically set a range of security headers from your Express.js app. While Helmet applies default security settings, customization may be required for specific use cases to ensure compatibility with APIs, especially setting up CORS to handle cross-origin requests correctly and securely.</p> <pre class="wp-block-code is-style-code-highlighter"><code>const helmet = require('helmet'); app.use(helmet());</code></pre> <h2 class="wp-block-heading">How to check your security headers</h2> <p>You can verify whether your security headers are properly configured using the following methods:</p> <ul class="wp-block-list"> <li><strong>DAST scanning</strong>: Use a vulnerability scanner for dynamic application security testing (DAST) to scan for missing and misconfigured HTTP security headers.</li> <li><strong>Browser developer tools</strong>: Open the browser’s developer console (F12 in most browsers) and check the Network tab for HTTP response headers.</li> <li><strong>Online security header checkers</strong>: Online tools are available that inspect site headers and provide recommendations.</li> <li><strong>cURL command</strong>: Simply open your terminal and run the command <code>curl -I https://example.com</code> to display the response headers.</li> </ul> <h2 class="wp-block-heading">Keep track of your HTTP security headers with Invicti</h2> <p>Implementing HTTP security headers can be an easy way to enhance web security, often requiring minimal or no modifications to the application itself. However, keeping up with evolving browser vendor support can be challenging, particularly when managing security configurations across numerous websites. Because security standards change frequently, ensuring your headers remain effective requires regular updates and monitoring.</p> <p>To help maintain strong security, Invicti includes vulnerability checks that assess the presence and correctness of recommended HTTP security headers. These automated checks detect missing or improperly configured headers and provide clear guidance on how to optimize them. This ensures your web applications remain protected against emerging threats and you can quickly catch any gaps caused by new or modified deployments.</p> <a class="invicti-block button-block btn btn--primary" href="https://www.invicti.com/get-demo/" target="_self" id="btn_67ef8d8dc1cb3" > Start testing for security misconfigurations today </a> <p></p> <hr class="wp-block-separator has-alpha-channel-opacity is-style-default" /> <h2 class="wp-block-heading">Frequently asked questions about missing security headers</h2> <div class="invicti-block accordion style-one" id="accordion_67ef8d8dc2431"> <div class="accordion-section"> <h4 class="accordion-heading">How to fix the vulnerability “HTTP security header not detected”?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>To fix this issue, determine which specific header is missing and add it to your web server configuration or application code. Use tools like curl, browser dev tools, or security scanners to verify the presence of essential headers.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">How to fix a missing Content Security Policy header?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Define and implement a strict Content Security Policy (CSP) in your server settings. For example, in Apache, you could specify <code>Header set Content-Security-Policy "default-src 'self'; script-src 'self'"</code> to block loading scripts and other content from external sources.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">Can I add security headers at the application level?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Yes, if your application is built with a framework such as Express.js, Django, or Flask, you can configure security headers within the application code using security-focused middleware.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">What happens if I add too many restrictions?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>Overly strict security headers may disrupt site functionality. For example, an overly restrictive X-XSS-Protection header can lead to unexpected behavior in web browsers, while a Content Security Policy (CSP) that blocks all inline scripts can prevent legitimate inline JavaScript from executing. Always test changes in a staging environment before deploying them to production. To test CSP directives before enforcing them, you can also use CSP in report-only mode.</p> </div> </div> </div> <div class="accordion-section"> <h4 class="accordion-heading">Are security headers enough to protect my web application?</h4> <div class="accordion-text-holder"> <div class="accordion-text"><p>HTTP security headers are only one part of a defense-in-depth strategy (though an essential one) and must be combined with secure coding practices, vulnerability testing, and proper access controls.</p> </div> </div> </div> </div> <p>The post <a href="https://www.invicti.com/blog/web-security/missing-http-security-headers/">Missing HTTP security headers: Avoidable risk, easy fix</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>DAST vs. penetration testing: Key similarities and differences</title> <link>https://www.invicti.com/blog/web-security/dast-vs-penetration-testing/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Wed, 12 Feb 2025 13:38:26 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[dast]]></category> <category><![CDATA[penetration-testing]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=47110</guid> <description><![CDATA[<p>Automated vulnerability scanning with DAST tools and manual penetration testing are two distinct approaches to application security testing. Though the two are closely related and sometimes overlap, they differ (among other things) in scope, efficiency, and the types of security vulnerabilities found.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/dast-vs-penetration-testing/">DAST vs. penetration testing: Key similarities and differences</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <h2 class="wp-block-heading">Understanding DAST and pen testing</h2> <p>It can be tempting to fall into checklist mode in cybersecurity, if only for the peace of mind of ticking off the required compliance items. For web application security, some organizations still treat their periodic penetration test or vulnerability assessment as a formality to tick their “application security testing” box, which will never be enough to effectively manage security risk. Ideally, you need a continuous testing process that’s part of your wider security program—but can penetration testing provide the required coverage? And what about DAST and all the other automated testing methods out there?</p> <p>This post goes into the key similarities and differences between automated and manual approaches to<a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/"> dynamic application security testing (DAST)</a> and shows that it should never be an either-or choice between pentesting and DAST.</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <p>Technically speaking, any method of security testing that probes a running app from the outside (black-box testing) qualifies as DAST, whether manual or automated. However, in common use, the term DAST usually refers to automated vulnerability scanning, while manual dynamic security testing is called penetration testing.</p> </blockquote> <h2 class="wp-block-heading">Similarities between DAST and penetration testing</h2> <p>At a high level, manual penetration testing and automated scanning with DAST tools are intended to achieve the same fundamental goal: find and report security vulnerabilities in the applications under test. The similarities encompass both the general methodology and the goals of both approaches:</p> <ul class="wp-block-list"> <li><strong>Identifying security weaknesses</strong>: Application vulnerability scanning and penetration testing both focus on detecting security vulnerabilities in web applications and systems. They achieve this by actively probing applications for security flaws, including misconfigurations, weak authentication, and exploitable vulnerabilities.</li> <li><strong>Black-box testing approach</strong>: Both automated DAST and penetration testing are black-box testing methods, meaning they assess security from the outside by probing a running application without needing source code access. This outside-in approach is technology-agnostic to test everything that is running for a realistic view of the overall security posture.</li> <li><strong>Real-world attack simulation</strong>: When testing running apps, DAST tools and pentesters alike use techniques that mimic real cyberattacks, such as <a href="https://www.invicti.com/learn/sql-injection-sqli/">SQL injection</a>, <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">cross-site scripting (XSS)</a>, and authentication bypass attacks. This gives the most accurate picture of the current exposure and security risk in the face of real-life cyber threats.</li> <li><strong>Security prioritization and remediation guidance</strong>: The outputs of both methods are vulnerability reports categorized by severity and potential impact. Leading DAST tools can match penetration testers in the confidence level that a reported issue is remotely exploitable, helping security teams prioritize remediation based on immediate risk.</li> <li><strong>Risk management and compliance requirements</strong>: Application security testing is often a compliance requirement to meet regulatory or industry standards, with both automated DAST and penetration testing playing a crucial role in meeting those requirements. In practice, most organizations will employ a combination of both methods.</li> </ul> <h2 class="wp-block-heading">Differences between DAST and penetration testing</h2> <p>Some kind of vulnerability scanner is an essential part of any pentester’s toolkit, helping to map out the application environment and find likely weak spots for further manual investigation. However, fully automated and integrated DAST differs from pentesting in several fundamental ways:</p> <ul class="wp-block-list"> <li><strong>Security testing coverage</strong>: Pentesters are limited by time and assignment scope, often focusing on business-critical or recently changed applications. A good quality DAST solution, on the other hand, can scan entire web environments automatically and repeatedly, covering not only first-party code but also vulnerabilities in third-party libraries, APIs, and runtime configurations, even if these change frequently.</li> <li><strong>Speed and cost</strong>: As a manual process, penetration testing is slow and expensive, requiring advance planning and budgeting and potentially leaving security gaps in between assessments. Automated DAST tools can, once set up, run any number of automated scans at any time with no additional cost, making them ideal for <a href="https://www.invicti.com/blog/web-security/what-is-devsecops/">continuous security in DevSecOps</a> environments, where stopping a sprint to wait for pentest results is impractical.</li> <li><strong>Depth and breadth of testing</strong>: The goal of penetration testing is in the name: to see if defenses can be penetrated and the organization breached. Accordingly, a pentester may only report a few instances of a recurring vulnerability and leave your teams to identify and fix similar cases. Automated DAST scanning, in contrast, provides more comprehensive coverage by running hundreds of automated security checks per asset at scale. With a good quality tool, you can establish and maintain a security baseline between in-depth manual testing commissions.</li> </ul> <ul class="wp-block-list"> <li><strong>Ease of remediation</strong>: Pentest reports may point out security risks but typically lack guidance on fixing vulnerabilities, leaving security teams and developers to work out remediation methods on their own. Advanced DAST tools are designed to integrate directly into CI/CD pipelines and issue trackers, providing developers with accurate vulnerability reports complete with remediation guidance. Invicti specifically uses proof-based scanning to cut down on false positives and ensure only actionable security issues reach developers.</li> <li><strong>Types of vulnerabilities found</strong>: Both approaches can detect common security flaws like SQL injection and XSS, but pentesters are best employed chaining exploits to simulate real-world attack scenarios and identifying business logic vulnerabilities. A good DAST tool should catch the vast majority of “easy” vulnerabilities for you to find and fix in-house, letting security professionals focus on higher-value flaws.</li> </ul> <h2 class="wp-block-heading">When to choose DAST</h2> <p>Automated vulnerability scanning with DAST is essential for continuous and scalable security testing across entire application environments. Unlike penetration testing, which is time-consuming and often limited in scope, DAST can rapidly scan multiple websites, applications, and APIs for a wide variety of common vulnerabilities. This makes it especially valuable in DevSecOps workflows, where frequent security testing lets teams catch and fix security issues early without slowing down development—and do it in-house without waiting for external processes.</p> <p>Uniquely among application security testing methods, DAST can be used both in AppSec and in InfoSec, enabling scheduled, automated scans that detect vulnerabilities as applications evolve from development through to production deployments. When integrated with CI/CD pipelines, especially in combination with static application security testing (SAST) tools, DAST helps enforce security hygiene throughout the software development lifecycle (SDLC) and minimizes the risk of vulnerabilities making it into production. When used for operational security, the same DAST gives security teams a real-time, fact-based view of the security posture of their entire organization.</p> <h2 class="wp-block-heading">When to choose penetration testing</h2> <p>Manual penetration testing gives you a point-in-time assessment of your resilience in the face of a determined attacker. Depending on the defined scope, pentesters will often look not only for application vulnerabilities but for exploitable security issues overall, spanning multiple areas of security and types of attacks if needed. Unlike automated tools, pentesters can adapt their methods during the assignment to chain together multiple smaller weaknesses or discover and exploit business logic vulnerabilities such as broken authentication flows or privilege escalation bugs.</p> <p>Pentesting is also needed for high-stakes security assessments, such as regulatory audits, red team exercises, or testing critical applications that store sensitive data. In cases where applications rely heavily on custom authentication mechanisms, non-standard APIs, or complex integrations, manual testing ensures a thorough evaluation of security risks. While DAST excels at frequent and scalable vulnerability detection, penetration testing works best for deep, targeted assessments that require human expertise.</p> <p><a href="https://www.invicti.com/case-studies/channel-4-case-study/">Read how bringing security testing in-house with DAST saved Channel 4 thousands of dollars a year on penetration testing.</a></p> <h2 class="wp-block-heading">Examples of DAST and penetration testing tools</h2> <p>Web vulnerability scanners are by far the most popular type of DAST tool. Every DAST tool has a vulnerability scanning engine, but different products vary widely in terms of capabilities and additional functionality—not to mention the quality of the scan engine itself. At one end of the spectrum, you have basic vulnerability scanners that only run a scan using an open-source engine and return results. At the other end are full-featured DAST-based platforms such as that offered by Invicti, where a proprietary scan engine is the heart of a comprehensive AppSec solution that covers multiple pre-scan and post-scan steps as well as integrating with other automated testing tools and external workflows.</p> <p>Penetration testing, on the other hand, relies on both automated and manual techniques to simulate real-world attacks. Web application pentesting often starts by running a pentesting vulnerability scanner and then uses a variety of manual tools to investigate potential vulnerabilities in more depth and escalate access whenever possible. Penetration testers can also use specialized tools for network reconnaissance, password cracking, traffic analysis, fuzzing, exploit development, and more to get a more realistic picture of an organization’s exposure to security threats.</p> <h2 class="wp-block-heading">Keeping your web apps and APIs secure goes beyond DAST vs. penetration testing</h2> <p>Application security testing has gone from a just-in-case proposition to a non-negotiable requirement. As application architectures and deployment modes get ever more distributed and complex, it’s no longer enough to rely only on perimeter defenses like web application firewalls—first and foremost, the underlying application itself needs to be secure. Any AppSec program worth its salt should incorporate a layered and comprehensive approach to security testing, using the right testing methods at the right time to minimize the number of application vulnerabilities at every stage of development and operations.</p> <p>In an industry swimming with acronyms, an advanced DAST-first platform offers the unique ability to unify and fact-check multiple testing tools while covering both information security (to scan your organization’s own attack surface) and application security (to test the apps you’re developing and running). Combined with the scalability and tech-agnostic nature of automated vulnerability scanning, this makes DAST foundational to any cybersecurity program. Use dynamic application security testing to <a href="https://www.invicti.com/penetration-testing-software/">bring security testing in-house</a> and fix everything you can, and only then call in the security experts and ethical hackers as part of a penetration test or bug bounty program.</p> <h2 class="wp-block-heading">Final thoughts</h2> <p>Remember the MOVEit Transfer crisis? (If not, we’ve covered it<a href="https://www.invicti.com/blog/web-security/moveit-transfer-breaches-perfect-storm-of-application-security/"> here</a> and<a href="https://www.invicti.com/blog/web-security/moveit-transfer-sql-injection-global-data-breaches/"> here</a>.) The resulting attacks that ultimately affected hundreds of organizations were only possible because malicious hackers combined several simple and normally inaccessible vulnerabilities into a devastating attack chain. Just like a penetration tester, the attackers used their human ingenuity to devise an attack path—but if those basic vulnerabilities had been found by automated scanning at earlier stages of the development process, all those MOVEit Transfer data breaches might not have happened.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/dast-vs-penetration-testing/">DAST vs. penetration testing: Key similarities and differences</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>DAST vs. SAST: Getting real on static and dynamic application security testing</title> <link>https://www.invicti.com/blog/web-security/dast-vs-sast-fact-check-on-static-and-dynamic-application-security-testing/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Fri, 07 Feb 2025 16:50:03 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[dast]]></category> <category><![CDATA[application-security-testing]]></category> <category><![CDATA[sast]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=17993</guid> <description><![CDATA[<p>Dynamic and static application security testing, or DAST and SAST, offer two different ways to test applications for vulnerabilities. Each has its advantages and its place in an application security program, making it important to understand how to choose and integrate the right tools to determine and improve your security posture.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/dast-vs-sast-fact-check-on-static-and-dynamic-application-security-testing/">DAST vs. SAST: Getting real on static and dynamic application security testing</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p>Getting lost in cybersecurity jargon, AppSec acronyms, and vendor claims? Here’s your guide to what two of the major application security testing technologies can and cannot do—and why you should be worrying more about getting the big picture of your application security risks and less about deciding between acronyms.</p> <h2 class="wp-block-heading">What is DAST and what is SAST?</h2> <p>Let’s start by getting the definitions out of the way and clarifying what each testing approach is designed to do.</p> <h3 class="wp-block-heading">What is DAST?</h3> <p><a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/">Dynamic application security testing (DAST)</a> is a black-box testing methodology where a running application is tested from the outside. While dynamic testing is a broad term that encompasses both manual and automated methods, DAST is usually understood to mean automated vulnerability scanning.&nbsp;</p> <h3 class="wp-block-heading">DAST testing tools</h3> <p>Dynamic application security testing tools (aka vulnerability scanners) analyze applications while they’re running, identifying critical security flaws by simulating attacks in a runtime environment. This provides an attacker’s eye view of your application security posture so you can fix potential vulnerabilities before they’re exploited. DAST tools vary in capabilities, from basic manual scanners to full enterprise-grade security platforms such as offered by Invicti.&nbsp;</p> <h3 class="wp-block-heading">When should I use DAST?</h3> <p>Because dynamic application security testing requires a running application, it is commonly used in staging to detect runtime vulnerabilities that were not present during development as well as other security flaws that weren’t detected earlier. Advanced DAST tools can also be used in production as an operational security tool and even integrated into CI/CD pipelines to test builds as early as possible.</p> <h3 class="wp-block-heading">What is SAST?</h3> <p><a href="https://www.invicti.com/learn/static-application-security-testing-sast/">Static application security testing (SAST)</a> is a security testing method that analyzes the application source code to identify potential security vulnerabilities. Because it requires knowledge of application internals, SAST is classified as a white-box testing approach.</p> <h3 class="wp-block-heading">SAST testing tools</h3> <p>Static application security testing tools analyze source code prior to deployment of the app, allowing early detection of security flaws during the development process. SAST tools range from IDE plugins to standalone static analyzers and are nearly always tightly integrated into dev pipelines.&nbsp;</p> <h3 class="wp-block-heading">When can I use SAST?</h3> <p>Because they operate on source code and don’t require a running app, SAST scans are used almost exclusively during development work. Depending on the tool, they can run continuously or be triggered at predefined stages in the pipeline.&nbsp;</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <h2 class="wp-block-heading">What is IAST, then?</h2> <p><a href="https://www.invicti.com/learn/interactive-application-security-testing-iast/">Interactive application security testing (IAST)</a>, sometimes called gray-box testing, occupies the middle ground between dynamic and static analysis. Depending on the vendor and product, IAST can be a standalone tool that adds dynamic insights to SAST or a way to add source code insights to DAST.&nbsp;</p> <p>&nbsp;</p> <p>IAST on the Invicti platform is implemented as a server-side agent that communicates with the core vulnerability scanner during testing to find more than DAST alone could without requiring code instrumentation.</p> </blockquote> <h2 class="wp-block-heading">SAST vs. DAST: Which should you use?</h2> <p>Static and dynamic approaches to security testing each have their strengths and limitations. While your overall application security program should ideally include both DAST and SAST to maximize coverage, deciding when to use each method depends on your organization, workflows, and specific tool choices.&nbsp;</p> <p>As a rule of thumb, SAST works best in early development. Because they operate on source code and are designed specifically to work in development toolchains, SAST tools are easy to build into CI/CD pipelines and the overall dev process. They are also the natural choice for enforcing secure coding best practices.</p> <p>DAST requires a running application, so it’s typically used in pre-prod and staging to find runtime vulnerabilities and also test third-party components, dynamic dependencies, and APIs used by the app. Being tech-agnostic, DAST is extremely versatile and can also be used in production to cover many use cases in operational and information security, including real-time security assessments as well as compliance and security audits. It can also serve to partially automate penetration testing.</p> <p>DAST and SAST are especially powerful when used in tandem. For example, you can automate SAST in CI/CD, scan major builds with DAST internally, and then also run scheduled DAST scans in production. This is especially important in heavily regulated industries like finance, healthcare, and government.&nbsp;</p> <h2 class="wp-block-heading">SAST vs. DAST coverage in web application security testing</h2> <p>Test coverage within a specific app and across your entire web application environment is a fundamental attribute of security testing. To give you an accurate picture, a security testing tool needs to know what to test, how to test it, and how to interpret and present the findings.</p> <p>SAST works on the application source code, so you need to have that code as well as tools that support a specific programming language and web application framework. If you have multiple technology stacks, you could need multiple SAST tools. In practice, SAST coverage is also limited to apps that are in active internal development since you need both the code and the right testing toolchains. The common argument that only SAST provides full test coverage because it tests all the code is only true for the codebase of a specific application—and the limited subset of vulnerabilities that can be detected statically.</p> <p>DAST tools, on the other hand, are technology-agnostic because they test applications from the outside and examine their behavior, not their source code. This allows DAST scans to cover any number of applications, regardless of tech stack, development status, or source code availability, testing everything that is externally accessible to a visiting browser. Leading dynamic scanners can identify a wide range of vulnerabilities, including misconfigurations and other runtime issues. They also support modern authentication schemes to access site sections and functionality available only to authenticated users.</p> <blockquote class="wp-block-quote is-style-quote-tips is-layout-flow wp-block-quote-is-layout-flow"> <h3 class="wp-block-heading">API security testing</h3> <p>Application programming interfaces (APIs) are the lifeblood of the cloud and gatekeepers of the data delivered by web services. Doing security testing on API endpoints is now a critical requirement to prevent data breaches—and leading DAST solutions provide an automated way to do this.</p> <p>&nbsp;</p> <p>Get the Invicti white paper on <a href="https://www.invicti.com/blog/web-security/avoid-api-blind-spots-in-web-application-security-testing-announcing-white-paper/">API security testing</a> to learn why API security is now an integral part of AppSec.</p> </blockquote> <h2 class="wp-block-heading">Security testing accuracy and efficiency with SAST vs. DAST</h2> <p>False positives have always been problematic in automated security testing, understood both as erroneous results and valid but non-actionable findings. In particular, many SAST tools have a reputation for flooding developers with security issues that, while often technically accurate, are irrelevant in a specific context. At best, this requires tedious fine-tuning—and at worst, developers will routine ignore SAST results or bypass the checks altogether.</p> <p>The advantage of DAST is the ability to look at the running app and identify actual exploitable vulnerabilities instead of just flagging suspicious code constructs. While basic vulnerability scanners can struggle to deliver fully reliable results, advanced DAST solutions can automatically and safely exploit many classes of vulnerabilities to confirm they are real and high-priority issues. This makes DAST the ideal approach for time-strapped development teams, allowing them to focus remediation on vulnerabilities that really matter.</p> <p><a href="https://www.invicti.com/blog/web-security/how-accurate-security-vulnerability-scanning-saves-money-visual-guide/">Learn more about proof-based scanning on the Invicti platform.</a></p> <h2 class="wp-block-heading">Finding vulnerabilities with DAST and SAST</h2> <p>To give a specific example, let’s say an application fetches data from an SQL database and insecurely uses raw user input from a web form in its database query:</p> <ul class="wp-block-list"> <li>SAST will identify the source code fragment that does this and warn the developer that the SQL query is constructed in a way that could (in theory) allow <a href="https://www.invicti.com/learn/sql-injection-sqli/">SQL injection</a>.</li> <li>A DAST scan will find the page and web form during crawling and simulate SQL injection attacks against it. If any of the test attacks succeed, the scanner will report an actual SQL injection vulnerability on that page.</li> </ul> <p><strong>The difference between SAST and DAST results is the difference between “we should probably look at this” and “we need to fix this now.”</strong> This is especially important for weaknesses such as <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">cross-site scripting (XSS)</a>, where many suspicious code constructs will never lead to an actual exploitable vulnerability. Advanced DAST tools can even identify out-of-band vulnerabilities, which are security gaps that don’t cause direct reactions to testing.</p> <h2 class="wp-block-heading">Building SAST and DAST into your SDLC</h2> <p>Testing your applications for all types of vulnerabilities as early as possible in the software development lifecycle (SDLC) is crucial to fix security issues before they make it into production. Source code analysis is the most natural way to find and eliminate security defects during early development. SAST is typically easy to integrate with development environments and workflows, whether as an IDE checker or a standalone analysis process. However, because SAST only looks at static code and cannot identify runtime vulnerabilities and misconfigurations, some form of dynamic testing is still needed in the SDLC.&nbsp;</p> <p>DAST tools also can and should be integrated into the SDLC. While they do require a runnable application to test, this is less of a hindrance with modern web frameworks that can autogenerate code for prototyping at any stage of development. The big advantage of DAST in the SDLC is that it can run at multiple stages of your pipeline, from partial testing in development to full-scope tests in staging and then production testing by security teams. In fact, because DAST is technology-agnostic and checks the entire application for vulnerabilities, regardless of the implementation details and source code availability, it’s the recommended starting point for <a href="https://www.invicti.com/white-papers/security-at-the-speed-of-software-dast-in-the-sdlc/">adding security testing into the SDLC</a>.</p> <h2 class="wp-block-heading">DevSecOps on the Invicti platform: Never mind the acronyms, give me results</h2> <p>It’s all too easy to get drawn into choosing one approach over another or (worse still) ticking boxes to make sure you catch all the AST acronyms. The ultimate goal, though, isn’t to complete a shopping list but to find a way to get your web applications secure and keep them secure. The way to get there is different for each organization and rarely quick or easy. At Invicti, we’ve come up with a fast-track approach that builds on the unique capabilities and features of our DAST-first AppSec platform.</p> <p>The Invicti platform is built around the industry’s most mature and advanced DAST scanning engine, which uses proof-based scanning to automatically confirm the vast majority of exploitable high-impact vulnerabilities with no risk of false positives. These confirmed results can be sent directly to developers via out-of-the-box integrations with issue trackers and CI/CD pipelines to make sure that application security can keep up with the extensive automation of DevOps development processes. Each vulnerability report includes detailed remediation guidance and each fix can be automatically retested, enabling organizations to set up a hands-off AppSec process that doesn’t interfere with development and leads to more secure code in the long run.</p> <p>With Invicti’s comprehensive security platform, you can stop counting your AST acronyms and start taking real control of your security posture. Yes, you do get DAST, SAST, IAST, SCA, API security, and much more besides, but instead of focusing on the tools, you can now finally focus on real-life security improvements—with the world’s best DAST engine keeping things honest.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/dast-vs-sast-fact-check-on-static-and-dynamic-application-security-testing/">DAST vs. SAST: Getting real on static and dynamic application security testing</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> <item> <title>Is DAST only for web applications? A fact-check on vulnerability scanning</title> <link>https://www.invicti.com/blog/web-security/is-dast-only-for-web-applications/</link> <dc:creator><![CDATA[Zbigniew Banach]]></dc:creator> <pubDate>Fri, 31 Jan 2025 17:01:01 +0000</pubDate> <category><![CDATA[Web Security]]></category> <category><![CDATA[dast]]></category> <guid isPermaLink="false">https://www.invicti.com/?p=101627</guid> <description><![CDATA[<p>Securing sprawling web application and API environments can be a constant game of whack-a-mole. To know and control their realistic attack surface, security teams need a way to find and test everything that’s running—and do it consistently, as often as they need. That’s why a DAST-based application security platform is fast becoming the CISO’s tool of choice.</p> <p>The post <a href="https://www.invicti.com/blog/web-security/is-dast-only-for-web-applications/">Is DAST only for web applications? A fact-check on vulnerability scanning</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></description> <content:encoded><![CDATA[ <p>The lines between websites, web applications, web services, APIs, and even mobile applications are becoming increasingly blurred. Web technologies are now the default choice for software development, with frontends talking to backends via APIs in complex distributed architectures and deployment models. When it’s hard to say exactly where “the application” begins and ends, finding a reliable way to test for security gaps requires tools and methods that can give you the big picture.</p> <p>The challenge of “test everything we’re running, whatever it is and wherever it’s running” can only be handled through <a href="https://www.invicti.com/learn/dynamic-application-security-testing-dast/">dynamic application security testing (DAST)</a>, which in its automated form is commonly called vulnerability scanning. In the process of probing the external attack surfaces of web applications for security gaps, today’s advanced DAST tools do far more than just test some web pages for <a href="https://www.invicti.com/learn/cross-site-scripting-xss/">XSS</a>. When done right and integrated into your workflows and overall AppSec program, DAST is uniquely positioned to give you a realistic view of your security posture.</p> <h2 class="wp-block-heading">What is DAST used for?</h2> <p>DAST solutions are used to automatically test for application vulnerabilities from the outside in. Historically, they started out as simple scripts used to aid manual penetration testing by automating the process of trying out multiple variations of different attacks. Modern DAST products range from basic manual scanners, where you get a scan engine and not much else, to full-featured AppSec platforms that allow organizations to make security testing an integral and scalable part of their development and operations.</p> <p>The outside-in approach to security testing makes DAST uniquely versatile, with major use cases covering both InfoSec and AppSec and including at least:</p> <ul class="wp-block-list"> <li>Website vulnerability scanning</li> <li>API security testing</li> <li>Security testing in the SDLC</li> <li>Automated penetration testing</li> <li>Vulnerability assessment</li> <li>Regulatory compliance</li> </ul> <h2 class="wp-block-heading">When is DAST an appropriate solution?</h2> <p>Some form of application security testing is a non-negotiable requirement for any organization that runs and especially develops web applications—meaning practically every sizable company and institution in the world. Among the many complementary approaches to security testing, DAST has the distinction of being usable, useful, and scalable regardless of the technology stack, development status, source code availability, or deployment model.</p> <p>Making a good DAST solution the centerpiece of your AppSec program can make the difference between being in control of your security and always fighting fires. For a start, integrating and automating DAST can give you a continuous vulnerability testing process that fills the time and coverage gaps in between periodic penetration testing. By running your own vulnerability scans already in pre-production and fixing identified flaws, you also get more value from pentesting and bounty programs by handling the “easy” issues internally. Finally, a high-grade DAST can verify exploitability, showing you which vulnerabilities need priority action while also acting as a fact-checker for <a href="https://www.invicti.com/learn/static-application-security-testing-sast/">static application security testing (SAST)</a> and other findings.</p> <h2 class="wp-block-heading">Does DAST require a running application?</h2> <p>Dynamic testing is, by definition, performed on a running application or system. However, what may have been a DAST limitation in the days of monolithic codebases and extended deployment processes is often not a major problem today. With application frameworks and especially with containerized components, it’s common to have some kind of runnable app at most stages of the development and testing process, even if it’s not yet a full build. By using DAST at multiple stages of the pipeline, you can start security testing as early as practically possible while gradually extending coverage as you move closer to production.</p> <h2 class="wp-block-heading">Can DAST be used for more than just web applications?</h2> <p>Time to finally answer the title question and also confess to a little word trickery. Exactly what qualifies as a “web application” depends on your definition in a specific context, but the practical upshot is that <strong>DAST absolutely can and should be used to test any running software built with web technologies</strong>. So when you’re scanning a complex web app that has an admin panel website, exposes several APIs, internally uses dozens of web services, and communicates with a backend relational database—what are you really testing? With an enterprise-grade DAST, you can test all these parts of your application environment and more.&nbsp;</p> <h3 class="wp-block-heading">Using DAST for API security testing</h3> <p>In theory, APIs—being specifically designed for automated access—seem like an obvious target for vulnerability scanning. In practice, it takes years of work to develop reliable security checks for APIs while also properly supporting all major specification formats. For the Invicti AppSec platform, <a href="https://www.invicti.com/product/api-security/">API security testing</a> is handled by a dedicated DAST module and (uniquely) also accompanied by comprehensive API discovery within the same platform.</p> <h3 class="wp-block-heading">Testing for server misconfigurations</h3> <p>Just as attackers will take advantage of any weakness they can find, DAST can probe your application environments not only for application-specific vulnerabilities like injections but also for security gaps in the way your servers are set up. This typically means analyzing server responses to flag security issues such as missing or incorrect security headers, but it can also include other security checks related to how the server is set up.</p> <h3 class="wp-block-heading">Finding database misconfigurations</h3> <p>Most applications are backed by some sort of database, so identifying database-related vulnerabilities such as SQL injection is the bread and butter of DAST scanning. Letting an attacker send commands to your backend database is bad enough, but really serious breaches happen when that database is insecurely set up and allows access to tables and operations that the application shouldn’t be touching in the first place. Advanced DAST security checks can reveal not only the injection points but also the consequences of insecure database server configurations.&nbsp;</p> <h3 class="wp-block-heading">Scanning mobile application backends</h3> <p>While DAST doesn’t scan mobile applications directly on a local device, many of those apps are merely a mobile frontend for sending and receiving API calls to and from a backend that does all the heavy lifting. And because advanced DAST solutions can also scan APIs, you can use them to perform security testing on the backends and services used by frontend apps—including mobile applications.</p> <h2 class="wp-block-heading">Bottom line: Application security is far more than scanning web pages</h2> <p>Application security has come a long way since the piecemeal efforts and tools used in the past—and with so many critical business systems now living in the cloud, the stakes are also far higher. CISOs and other security leaders now acknowledge that nobody will ever hand them a complete and carefully maintained inventory of every attack point across their organization’s sprawling application environments, much less a detailed security testing report for each app and API. Instead, they are taking charge by finding technical solutions that let them and their teams find, test, fix, and continuously monitor their realistic web attack surface.</p> <p>Dynamic security testing is the only practical approach that can provide this level of coverage and visibility, making a DAST-first application security platform such as Invicti uniquely suited for the job. With the industry’s most advanced and accurate vulnerability scanning engine at its core, the Invicti platform adds application and API discovery, <a href="https://www.invicti.com/learn/software-composition-analysis-sca/">software composition analysis (SCA)</a>, outdated technology detection, vulnerability management, workflow integrations, and much, much more to bring all your application security under a unified DAST umbrella.</p> <a class="invicti-block button-block btn btn--primary" href="https://www.invicti.com/get-demo/" target="_self" title="Get a demo of the Invicti application security platform" id="btn_67ef8d8dcc16d" > Get a proof-of-concept demo today! </a> <p>The post <a href="https://www.invicti.com/blog/web-security/is-dast-only-for-web-applications/">Is DAST only for web applications? A fact-check on vulnerability scanning</a> appeared first on <a href="https://www.invicti.com">Invicti</a>.</p> ]]></content:encoded> </item> </channel> </rss>