Product overview
Invicti specializes in web application and API security, providing robust vulnerability scanning through Dynamic Application Security Testing (DAST) and other advanced methodologies. Vulnerabilities are identified across web apps and APIs by performing functional and behavioral tests, including port 80/443-based security checks. With features such as Predictive Risk Scoring (PRS) and Proof-Based Scanning (PBS), Invicti enables organizations to prioritize risks in their web apps and APIs effectively.
Why Invicti DAST
Modern application security needs to focus on real risk, not noise. A DAST-first approach ensures you are securing what actually matters—real, exploitable vulnerabilities in your running applications, rather than theoretical risks buried in static scans.
Invicti specializes in modern web application and API security, providing robust DAST-first vulnerability scanning.
A DAST-first approach focuses on what attackers see
- It scans live applications to find vulnerabilities that can actually be exploited.
Proof-Based Scanning eliminates false positives
- Invicti automatically validates vulnerabilities with proof-of-exploit, so you know what’s real.
Faster remediation, higher efficiency
- Security and development teams focus on fixing what matters most, reducing time wasted on non-issues.
How Invicti DAST works
Vulnerabilities are identified across web apps and APIs by performing functional and behavioral tests, including port 80/443-based security checks.
New to DAST?
We've got you covered. Invicti Learn was created by our team of security experts to educate you on vulnerabilities, attack vectors, protections, and tooling involved in application security.
Implementation phases
We're excited you've chosen Invicti as your application security platform.

To ensure you get the most out of your first 30 days and beyond with Invicti, we've outlined the important implementation milestones in this recommended order:
- Day 1 to 10: Gather, onboard, configure, and prioritize your first set of web apps and APIs to be scanned with Invicti.
- Day 11 to 20: Explore options in Invicti to help fine-tune your scan results and other customization capabilities along with scaling up your deployment.
- Day 21 to 30: Review and implement any needed integrations to help automate different parts of your workflow.
- Day 31+: Continue to expand your scanning footprint and review other continued engagement opportunities and features Invicti has to offer.
Phase 1: Gather, add and configure (days 1 to 10)
Onboard users, websites, and APIs, install agents, and trustlist IPs as needed, so you and other team members can start using Invicti to run scans and find vulnerabilities.
Add users
By providing access to other users, you can distribute responsibilities and tasks with various RBAC settings available with Invicti.
Configure SSO
If you are looking to onboard a large number of users and you are leveraging an SSO provider, Invicti can integrate with any IdP/SSO provider that supports SAML 2.0. Additionally, with Invicti SCIM, you can further automate the onboarding process with additional functionality such as creating users and groups.
Install agents
Agents are useful when scanning web applications and APIs hosted in your internal network. Invicti scan agents are available for different operating systems and only need to be installed on servers that have connectivity to the web applications and APIs to be scanned over port 80/443. When testing authentication for internal applications, a component known as the login sequence recorder is needed to assist in configuring the login sequence, which can be uploaded in the UI for the target's authentication configuration.
An agent can run concurrent scans, it depends on the resources allocated to the host where the engine is installed.
Trustlist IP addresses
Invicti scanner IPs may need to be trustlisted if you are scanning public-facing (external) web applications and APIs that reside behind a WAF. The main functionality of a WAF is to block incoming malicious traffic to your applications. Because of this, automated DAST scanners like Invicti may not be able to successfully test your web applications and APIs for vulnerabilities. To ensure successful testing or access to web applications and APIs with Invicti, it is recommended that you trustlist these IP addresses. Depending on your region, review the following.
Onboard websites and APIs
Once you have successfully installed agents and trustlisted IP addresses, you can scan either public-facing or internal web applications and APIs. Onboarding web applications and APIs in Invicti begins with identifying which domains and subdomains you want Invicti to scan. The scope of scanning can be further fine-tuned at a later stage, but it begins with identifying where you want to start scanning first: your external or internal-facing footprint of web applications and APIs.
Other settings such as scan profiles, authentication, and uploading API specification files can be done once a target has been added.
- Edit target settings
- Edit target scan configuration
- Scan authenticated targets
- Set excluded scanning hours
- Edit target settings
- Review default and custom scan profiles
- Business logic recorder
- Custom headers and cookies
Before moving on to Phase 2, make sure to start gathering other targets and authentication related information you may need to start scaling up your deployment.
Predictive risk scoring
As part of gathering targets, you may already be aware of all targets you intend to scan with Invicti. In the event that you need to review what targets Invicti has identified in its inventory based on Application discovery, you can review Discovery results for gathering unknown targets. Learn how to prioritize with Predictive risk scoring if you intend to onboard any of these targets to scan with Invicti.
Phase 2: Fine-tune, scale and revise (days 11 to 20)
As you move on to Phase 2 of implementation, you are now ready to start reviewing your first scans, identifying areas of improvement, and looking at ways to scale up your deployment to operationalize Invicti and build your application security program.
Review vulnerabilities
Once your first few scans with Invicti are completed, you will want to start reviewing your findings and identify opportunities to address any vulnerabilities or accept the risk. Vulnerabilities can be reviewed from different sections of Invicti, either from the scan summary page or the Issues tab. Below are some links to help you get started. You can manage issues found from scans based on your organization's security policies and practices.

Scan statuses in Invicti Platform.
Along with vulnerability information, you can also take actions such as retesting, ticket creation, and changing the status.

Invicti Platform scan statuses explained.
Reports
Once findings have been reviewed, you can generate reports to share with different stakeholders. Reports can be generated from the scan summary tab.
Fine-tune scans
As you review scan results, there may be other priorities you want to address before scaling up your implementation. Tasks such as reducing scan times, addressing scan failures, improving coverage, and getting more logging information can be done on a case-by-case basis.
When you think about fine-tuning scans, reviewing the common error messages is a good place to start. While some errors might be benign, some might be worth a second look.
Some common troubleshooting topics you may encounter are discussed below.
Advanced authentication
Authentication is a critical component of scan profile configuration. When properly configured, it enables the Invicti scanner to log into the application, allowing it to navigate to and assess vulnerabilities within endpoints that are otherwise inaccessible behind the login screen. Without authentication, the Invicti scan's scope is limited to crawling and testing only those endpoints that are publicly accessible.
As you gain experience with Invicti and run more scans, you might encounter scenarios where the scan coverage is inadequate despite seemingly correct authentication configuration, or the scan fails due to login issues, or the application requires a different authentication mechanism altogether. To assist you in troubleshooting such authentication-related issues, we offer comprehensive resources that delve deeper into common problems and provide effective solutions.
These resources will cover a wide array of topics, including step-by-step guides on configuring different authentication types, best practices for optimizing authentication settings, troubleshooting techniques for common login failures, and advanced strategies for handling complex authentication scenarios. By leveraging these resources, you can enhance your understanding of Invicti's authentication mechanisms, fine-tune your scan profiles, and ensure comprehensive coverage of your web applications during vulnerability assessments.
An important thing to remember is that the authentication you are configuring within Invicti will be replayed during a scan based on the perspective of where the scan is originating from. For example, scans run with Invicti's cloud agents will originate from Invicti-hosted IPs, and scans running from an internal agent will run from IPs and servers in your internal environment. This means that when troubleshooting authentication issues, it is crucial that you understand your application's authentication flow from the perspective of an incognito browser in different environments to correctly replicate and understand how Invicti will attempt to log in during a scan.
Review login sequence recorder
A login sequence recorder (LSR) is the component of the configuration you will likely be using in cases where you have authentication against your web applications with complex flows, such as through an SSO/IdP over multiple pages, multiple buttons to click to redirect to a login page, etc. Also, if you have Selenium recordings of your login flow, those files can also be uploaded and converted into an LSR.
Making sure your LSR will work correctly prior to running a scan is a key part of a correct configuration. You can replay the LSR to ensure you see it logging in correctly.
If for any reason you notice the LSR not replaying the authentication flow as expected, you can try some troubleshooting. A local version of the LSR is also available in case you need to record and validate from an internal perspective.
Multi-authentication setups
Authentication against an application should always be tested in a browser prior to configuring it in a scan profile. If you identify use cases where your application may use two or more types of authentication, these can be configured in a scan profile and used simultaneously during a scan. Some common use cases of multiple authentication setups include, but are not limited to, HTTP (Basic, Digest, NTLM, or Kerberos) + LSR, OAuth + HTTP, etc.
OTP
If you have an application where OTP-based MFA is needed, here are some potential steps you can take.
- If OTP has to be enabled, you can review the following articles for the relevant authentication configuration needed:
- Simple form authentication with OTP
- Time-based One-time passwords (TOTP) Document will be added soon.
- Some other alternative options include:
- Creating service accounts that are used solely for configuring authentication in automated testing and scanning purposes that have been approved to not require 2FA-based authentication. Any extra security protections applied to the authentication steps of an application are typically seen as bottlenecks for successful automated authentication.
- Reconfiguring your authentication to have security question-type MFA. With Invicti's LSR, multi-page authentication can be easily recorded, while also allowing the authentication setup process to be easily automated.
Pre-request scripts
There may be some authentication flows where a user is not interacting with an application in a web browser to enter a username and password to log in, but instead making an API call to a few endpoints to gather tokens that can be used to perform authenticated operations against other endpoints. In such instances, you can use a pre-request script, wherein a script will perform all the actions of getting a token prior to every request made by Invicti's scanner. To use this, you may need to contact Invicti support.
OAuth 2
Most web applications with authentication types that require a username and password which are typed in a web browser, are configured as a login sequence in Invicti with a recording. In instances where the intent is to only scan an API, configuring such a type of authentication might not be possible. Commonly seen authentication implementations for APIs are built on different OAuth2 flow types. OAuth2 is an authentication type that can be configured in Invicti.
Improve coverage
- Scan coverage can be reviewed via the site structure or the CSV locations export.
- When running a scan with Invicti, it is important to understand how your application works. If there is more than one subdomain involved in the application functionality, you may want to consider adding Additional hosts. These are needed to ensure Invicti can correctly visualize your application in a scan and assess it for vulnerabilities. You can review possible domains that may have been skipped during your first scan in the Discovered hosts section.
- Review your Crawling options. If you have changed some settings here, it may help to review them again in case the changes can help achieve the correct coverage.
- Different types of proxy capture files (e.g., Burp, Fiddler, .har) and API specification files (e.g., OpenAPI 3, RAML, WSDL) can be imported into Invicti to help increase coverage. These imported links are stored in the scan profile section of the configuration and used during the scan to allow the scanner to navigate to endpoints.
- An alternative to adding proxy capture files is the business logic recorder, which helps you record workflows and navigate to specific endpoints that the scanner may not have been able to reach on its own. (If you wish to only scan endpoints specified in the imported links or business logic recording, this setting can be enabled.)
- If you need to modify some scanning parameters to better crawl your application, it may be a good idea to review whether there are any important headers or cookies that need to be set to scan your application. You can review where Custom headers and cookies can be added.
Reduce scan times
As you continue to identify areas of improvement, reducing scan times might be an option to consider given your organization's security practices or web application development build cadence requirements. While there is no direct way to correlate the size of an application to how long a scan may take, there are some components to keep track of as you start to fine-tune settings in Invicti to help reduce scan times.
Logs
While you may not need to review logs generated in Invicti regularly, below is a list of places where you can gather different types of logs and their purposes.
- Audit logs: Review a user's activity within Invicti. These logs can also be sent to a SIEM via the Invicti API.
- Scan logs: Also available on the scan summary page, scan logs provide high-level information about a scan's performance. These logs need to be enabled in the backend with the help of a support ticket. They are mainly used for advanced troubleshooting and are enabled on a case-by-case basis.
As you approach the end of Phase 2, the tasks don’t end here. There is more to review with Invicti! You can continue performing activities listed in Phase 2, as you move on to Phase 3.
Phase 3: Automate, customize and operate (days 21 to 30)
Moving into Phase 3 of your implementation, you can identify opportunities to start automating your different workflows as you continue to use Invicti. Features such as notification workflows, CI/CD integrations, and ticketing integrations are some of the things you can review as you continue activities from Phase 2.
Applications, collections and projects
The Invicti Platform allows for grouping of your scanned assets in a couple of different ways.
API catalog
The Invicti Platform allows for grouping of your scanned assets in a couple of different ways.
CICD integrations
Once you have completed the tasks of optimizing your scan configurations to your liking, where average scan times, authentication issues, and coverage are optimal, you can start looking into Invicti's ability to integrate into your CI/CD pipelines and have scans initiated as part of your build steps. Invicti offers integration with Azure Pipelines, GitHub Actions, GitLab, and Jenkins.
By integrating Invicti into your CI/CD pipeline, you can start implementing DAST scanning earlier in the SDLC to identify real vulnerabilities in your pre-production, QA, and other staging environments. While scanning within and after each stage may not be needed, being able to identify vulnerabilities earlier in the lifecycle of developing web applications and APIs will help reduce the cost of having to fix them later if identified in production.
Ticketing integrations
As you have defined the cadence of running scans either on a schedule or ad hoc via the CI/CD integrations or even manually, automating the generation of tickets to ease the workload of post-scan analysis is possible. Invicti offers the ability to integrate with ticketing systems like Jira (OAuth or HTTPS basic token), Azure Boards, GitLab Issues, and GitHub Issues.
Automations
As you further look to automate different parts of Invicti, you can also customize which notifications are sent and how they are sent to different stakeholders in your organization depending on scope, types of vulnerabilities, and different reports.
As discussed in the previous section on how tickets can be created from Invicti into your ticketing systems, with notification workflows you can also automate the creation of those tickets. With options to filter out the noise and selectively create tickets only for your critical issues that are confirmed by Invicti's Proof-Based Scanning, you can be assured that tickets will only be opened for true findings.
Invicti API
Invicti offers a robust API wherein you can perform nearly all tasks that you would do when interacting with Invicti via a web browser with just a few API calls. Once you have reviewed all of the available out-of-the-box automation options Invicti has to offer and you have use cases that may need a custom-built solution, you can begin reviewing the Invicti Platform API and identify areas of automation that you may need to help with scaling up your deployment.
Once you have reviewed different areas of improving and automating your workloads pertaining to Invicti, you can continue refining your processes based on your business and security requirements and continue to iterate on your tasks from Phases 2 and 3 as you move into Phase 4.
Phase 4: Continued engagements or upgrades (days 31+)
As you approach the end of the first 30 days of familiarizing yourself with different capabilities of Invicti and automating different aspects of your workflows, you may want to explore additional capabilities of Invicti. If these were not already discussed prior to your onboarding or during your procurement phase, there are a few more capabilities and services you can review.
API discovery
Invicti also offers the capability to discover APIs being used and published in your environment. Capabilities include Zero-configuration discovery, Sensorless discovery, integration into API management platforms, and a Network Traffic Analyzer that can capture traffic to create an API inventory. Once configured, these options will allow Invicti to become your centralized API inventory platform from which you can pick and choose which APIs to onboard specifically and perform DAST testing against. This feature is available as an add-on.
Third party connections
If you are looking to further develop your application security program and leverage other solutions that can provide SAST, SCA, and container security, Invicti can connect with Mend.io to provide a single-pane-of-glass view into the vulnerabilities of your applications in one platform. This feature is available as an add-on.
Professional services
As you scale up your implementation of Invicti and have identified areas where you may need more assistance, you may want to look into leveraging the guidance of industry experts at Invicti who can help. While some services are offered as an extra add-on, the Professional Services team at Invicti can assist with tasks such as:
- Performing a health check 6+ months into your journey with Invicti to review your implementation and offer guidance on current best practices and process improvements.
- Creating scripts for automating different tasks and workflows based on your needs using the Invicti API.
- Writing pre-request scripts that can help address one-off authentication use cases that you may not have been able to address with the out-of-the-box automated authentication capabilities of Invicti.
Blogs
For further reading, Invicti has a great blog to stay up to date with the latest security news and best practices on how to leverage the solution to fit your business needs.
Support
For critical issues and immediate assistance, you have access to our support team. You can create an account here to open support tickets, keep track of them, and have access to other troubleshooting articles.
Need help?
The Invicti Support team is ready to provide you with technical help. Go to Help Center