Taint analysis

Taint analysis lets you trace the flow of potentially harmful or tainted data through a program. It identifies paths where untrusted input or sources might reach sensitive operations or sinks without proper validation or sanitization, which helps prevent security vulnerabilities like SQL injections, cross-site scripting (XSS), command injections, and path traversal. The core goal is to determine if unanticipated input can affect program execution in malicious ways.

Taint analysis is supported by IntelliJ IDEA Ultimate, as well as by the Qodana for PHP, Qodana for JVM, and the Qodana for .NET linters under the Ultimate Plus license. Information about available Qodana licenses is available on the Subscription Options and Pricing page. You can also request a demo.

This feature provides built-in taint rules for the most common categories of OWASP Top 10:2021 vulnerabilities (A01, A03, A07, A08, A10). In addition to the built-in rules, you can configure custom taint rules for your own application or library code, designating specific functions or methods as sources or sinks.

The taint analysis feature runs locally and does not require any external dependencies or services.

How taint analysis works

Tainted data is called a source, while a vulnerable function that may contain a source is called a sink.

Between a source and a sink, tainted data can travel through various passthrough functions whose calls are also marked as tainted if the input data was initially marked as tainted. The sanitizer functions can be used to make data safe for further processing through several approaches like data sanitization or data transformation to a safe state.

The projection approach lets you share the taint status across all arguments of a function call. This ensures that the taint status of the arguments is transferred to the return value.

Default behavior in IntelliJ IDEA

If there is no specific configuration available for a library function call, a projection will be applied by default. This means the taint status of the function arguments will be passed to the return value, maintaining the integrity of the taint analysis.

To override the default behavior, you can apply custom configurations to specific function calls.

Qodana for .NET

Starting from version 2026.2, the Qodana for .NET linter supports rules compatible with Opengrep for configuring taint analysis. It already includes a set of built-in C#, JavaScript, and TypeScript rules that you can use as Qodana inspections, so you don’t have to download or configure them manually. Examples of such rules are available in our GitHub repository. The list of supported rules is provided in the Qodana for .NET list of rules chapter.

Information about developing custom rules is available on the Semgrep website.

Before you start

This section explains how you can run taint analysis using IntelliJ IDEA and Qodana linters.

IntelliJ IDEA

Before you run taint analysis in your IDE, install the Security Analysis by Qodana plugin. To do it, in IntelliJ IDEA navigate to the Problems tool window and click the Security Analysis tab. On this tab, click the Install plugin button.

Alternatively, navigate to File | Settings | Plugins and install the Security Analysis by Qodana plugin.

Qodana linters

Taint analysis is available for the Qodana for PHP and Qodana for JVM linters once you invoke the qodana.recommended inspection profile:

version: 1.0
profile:
  name: qodana.recommended

For the Qodana for .NET linter, taint analysis is enabled by default.

Run taint analysis

IntelliJ IDEA

Navigate to the Problems tool window and then click the Security Analysis tab. On this tab, click the Run Taint Analysis button.
Alternatively, you can navigate to Tools | Security Analysis | Run Taint Analysis.
On the dialog that opens, configure the taint analysis.
Here you can configure the scope of files that you would like to analyze using taint analysis, as well as file masks for the analyzed files.
The Inspection options group contains several tabs:
Options applied to an opened file in real time.
The Analysis depth (from a current file) field configures analysis depth using the Current file → File 1 (Low) → File 2 (Medium) → File 3 (High) reference pattern. For example, the Medium setting configures the reference to File 2 from this pattern.
The Analysis time limit for in-editor analysis (ms) field configures the amount of time that can be allocated for a specific file. The default value is 5000 ms.
Configuration of batch analysis over an entire project.
The Analysis depth (from a current file) field configures analysis depth using the Current file → File 1 (Low) → File 2 (Medium) → File 3 (High) reference pattern. For example, the Medium setting configures the reference to File 2 from this pattern.
The Use caches during analysis field lets you use caching. While consuming disk space, it can improve analysis performance.
If enabled, the Enable computation expensive configurations checkbox involves additional analysis techniques that can improve output but will significantly impact performance.
Using the Safe classes box, you can configure the existing safe classes and define your own.

If no issues were detected, it is possible that the taint analysis configuration is incomplete. Make sure that you defined all necessary sources, sinks, and sanitizers, as explained in the Configure function calls chapter.

Explore results

In your IDE, point to a suspicious code fragment and then click the Show taint ... trace link to open the Security Analysis tab.

The left part of the Security Analysis tab contains all steps of a taint trace. The right part shows the code fragments corresponding to a specific step. You can click any step to see the source trace to the sink.

Navigating steps between a source and a sink

Configure function calls

The analysis of function calls is carried out using the default configuration in case a function call does not match any existing configuration. In this case, the taint analysis builds a projection for this function. The default configuration already covers basic sources, sinks, and sanitizers.

You can configure function calls as your custom sources and sinks as explained below. This example uses the following unconfigured function calls:

java.net.URI.getQuery can be configured as a source of tainted data to represent a point where potentially untrusted input enters the system.
java.io.OutputStream.write can be configured as a sink where potentially tainted data may be written to an output stream, such as a file or network socket.

In the upper-right part of the Security Analysis tab, click the context menu and then click the Highlight Taint Configuration link.
This will open the tab containing current configuration settings applied to all function calls or places where functions are called within the currently opened file.
If a function reference matches a specific configuration, the corresponding configuration will be highlighted indicating how it will be treated during analysis. The configuration for function references will appear in the list in the same order as references are located in the file.
In the list of projections, select the projection reference and apply a respective Quick-Fix option.
This will create the inspections/config.inspection.kts file for a source, sink, and sanitizer configuration. To ensure consistency of analysis reports save this file in the root directory of your project.
In the inspections/config.inspection.kts file, assign specific taint rules to a newly added sources and sinks. The configuration from this file is applied to the Taint Analysis inspection when the project opens.
For the java.net.URI.getQuery function call as a source, save this configuration to define a point where potentially untrusted input enters a system:
source( "java.net.URI.getQuery", "java.lang.String", TaintRule.allRulesList() )
For the java.io.OutputStream.write function call as a sink, save the following configuration to ensure that the data reaching the sink are verified for proper sanitization according to the chosen rule to prevent the propagation of unsafe data:
sink( "java.io.OutputStream.write", listOf(1), TaintRule.XSS )
Once the configuration is written, recompile the inspections/config.inspection.kts file.

Configure the Security Analysis tab

Configure the Security Analysis tab by navigating to File | Settings | Advanced settings. Here, find the Security Analysis section and then configure the Show Problem Tab checkbox.

Qodana linters

In the qodana.yaml file, include the PhpVulnerablePathsInspection inspection into the analysis scope:

  version "1.0"

  linter: qodana-php

  include:
    - name: PhpVulnerablePathsInspection

In the qodana.yaml file, include the JvmTaintAnalysis inspection into the analysis scope:

  version "1.0"

  linter: qodana-jvm

  include:
    - name: JvmTaintAnalysis

Qodana for .NET

Taint analysis is by default enabled for the Qodana for .NET linter. You can override the default behavior using capabilities explained below.

Set the number of traces

By default, taint analysis is configured for monitoring one hundred (100) traces at a time. You can override this using the dfa.analysis.rml.max.traces.count=<number> property, for example:

            docker run \
               -v $(pwd):/data/project/ \
               -e QODANA_TOKEN="<cloud-project-token>" \
               jetbrains/qodana-dotnet:2026.2 \
               --property=dfa.analysis.rml.max.traces.count=1000 
        

            qodana scan \
               -e QODANA_TOKEN="<cloud-project-token>" \
               --property=dfa.analysis.rml.max.traces.count=1000
        

        name: Qodana
        on:
            workflow_dispatch:
            pull_request:
            push:
                branches: # Specify your branches here
                    - main # The 'main' branch
                    - master # The 'master' branch
                    - 'releases/*' # The release branches
        jobs:
            qodana:
                runs-on: ubuntu-latest
                permissions:
                    contents: write
                    pull-requests: write
                    checks: write
                steps:
                    - uses: actions/checkout@v3
                      with:
                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                          fetch-depth: 0  # a full history is required for pull request analysis
                    - name: 'Qodana Scan'
                      uses: JetBrains/qodana-action@v2026.1
                      with:
                          args: --property=dfa.analysis.rml.max.traces.count=1000
                      env:
                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
    

            pipeline {
                environment {
                    QODANA_TOKEN=credentials('qodana-token')
                }
                agent {
                    docker {
                        args '''
                          -v "${WORKSPACE}":/data/project
                          --entrypoint=""
                          '''
                        image 'jetbrains/qodana-dotnet:2026.2'
                    }
                }
                stages {
                    stage('Qodana') {
                        steps {
                            sh '''
                            qodana \
                            --property=dfa.analysis.rml.max.traces.count=1000
                            '''
                        }
                    }
                }
            }
        

            include:
                - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2026.1
                  inputs:
                      args: |
                          --property=dfa.analysis.rml.max.traces.count=1000
                          --linter qodana-dotnet
        

In the runner configuration, find the Additional Docker arguments field and specify the property:

--property=dfa.analysis.rml.max.traces.count=1000

Disable bundled rules

You can disable the bundled rules by configuring the IDEA_PROPERTIES variable:

            docker run \
               -v $(pwd):/data/project/ \
               -e QODANA_TOKEN="<cloud-project-token>" \
               -e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false \
               jetbrains/qodana-dotnet:2026.2 \
        

            qodana scan \
               -e QODANA_TOKEN="<cloud-project-token>" \
               -e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false
        

        name: Qodana
        on:
            workflow_dispatch:
            pull_request:
            push:
                branches: # Specify your branches here
                    - main # The 'main' branch
                    - master # The 'master' branch
                    - 'releases/*' # The release branches
        jobs:
            qodana:
                runs-on: ubuntu-latest
                permissions:
                    contents: write
                    pull-requests: write
                    checks: write
                steps:
                    - uses: actions/checkout@v3
                      with:
                          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
                          fetch-depth: 0  # a full history is required for pull request analysis
                    - name: 'Qodana Scan'
                      uses: JetBrains/qodana-action@v2026.1
                      with:
                          args: -e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false
                      env:
                          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
    

            pipeline {
                environment {
                    QODANA_TOKEN=credentials('qodana-token')
                }
                agent {
                    docker {
                        args '''
                          -v "${WORKSPACE}":/data/project
                          -e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false  
                          --entrypoint=""
                          '''
                        image 'jetbrains/qodana-dotnet:2026.2'
                    }
                }
                stages {
                    stage('Qodana') {
                        steps {
                            sh '''qodana'''
                        }
                    }
                }
            }
        

            include:
                - component: $CI_SERVER_FQDN/qodana/qodana/qodana-gitlab-ci@v2026.1
                  inputs:
                      args: |
                          -e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false
                          --linter qodana-dotnet
        

In the runner configuration, find the Additional Docker arguments field and specify the property:

-e IDEA_PROPERTIES=intellij.opengrep.rules.downloaded.source.enabled=false

Use your own rules

In addition to the bundled rules, you can apply your own rules by saving rule files to the .qodana/opengrep directory of your project root.

Qodana for .NET list of rules

The repository containing rules is available on the GitHub website.

OWASP Top 2017 Coverage Matrix

Category	C#	JavaScript	TypeScript
A1 Injection	✓	✓	✓
A2 Broken Authentication	✓	✓	-
A3 Sensitive Data Exposure	✓	✓	✓
A4 XML External Entities (XXE)	-	✓	-
A5 Broken Access Control	✓	✓	✓
A6 Security Misconfiguration	✓	✓	-
A7 Cross-Site Scripting (XSS)	✓	✓	✓
A8 Insecure Deserialization	✓	✓	✓
A9 Using Components with Known Vulnerabilities	-	✓	✓
A10 Insufficient Logging & Monitoring	-	-	-

Information about these rules is available on the OWASP website.

OWASP Top 2021 Coverage Matrix

Category	csharp	javascript	typescript
A1 Broken Access Control	✓	✓	✓
A2 Cryptographic Failures	✓	✓	✓
A3 Injection	✓	✓	✓
A4 Insecure Design	✓	-	-
A5 Security Misconfiguration	✓	✓	-
A6 Vulnerable and Outdated Components	-	✓	✓
A7 Identification and Authentication Failures	✓	✓	-
A8 Software and Data Integrity Failures	✓	✓	✓
A9 Security Logging and Monitoring Failures	-	-	-
A10 Server Side Request Forgery (SSRF)	-	✓	✓

Information about these rules is available on the OWASP website.

04 August 2026