From cdbd55017d988a6a6db7b18c3f86e09eb4d92f2b Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Sat, 21 Feb 2026 22:34:28 +0000 Subject: [PATCH 1/5] (Trivial) Remove trailing spaces in some docs --- .../customizing-library-models-for-go.rst | 6 +++--- .../customizing-library-models-for-python.rst | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index c5b74ccd73ae..946ee1937b45 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -171,7 +171,7 @@ We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, s pack: codeql/go-all extensible: summaryModel data: - - ["slices", "", False, "Max", "", "", "Argument[0].ArrayElement", "ReturnValue", "value", "manual"] + - ["slices", "", False, "Max", "", "", "Argument[0].ArrayElement", "ReturnValue", "value", "manual"] Since we are adding flow through a method, we need to add tuples to the ``summaryModel`` extensible predicate. The first row defines flow from the first argument (``a`` in the example) to the return value (``max`` in the example). @@ -307,7 +307,7 @@ This example shows how the Go query pack models flow through a method for a simp host := u.Hostname() // There is taint flow from u to host. ... } - + We need to add a tuple to the ``summaryModel``\(package, type, subtypes, name, signature, ext, input, output, kind, provenance) extensible predicate by updating a data extension file: .. code-block:: yaml @@ -387,7 +387,7 @@ Note that packages hosted at ``gopkg.in`` use a slightly different syntax: the m To write models that only apply to ``github.com/couchbase/gocb/v2``, it is sufficient to include the major version suffix (``/v2``) in the package column. To write models that only apply to ``github.com/couchbase/gocb``, you may prefix the package column with ``fixed-version:``. For example, here are two models for a method that has changed name from v1 to v2. .. code-block:: yaml - + extensions: - addsTo: pack: codeql/go-all diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 30888f7b6092..69e6355e2096 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -9,7 +9,7 @@ Python analysis can be customized by adding library models in data extension fil A data extension for Python is a YAML file of the form: -.. code-block:: yaml +.. code-block:: yaml extensions: - addsTo: @@ -177,7 +177,7 @@ Note that this source is already known by the CodeQL Python analysis, but for th The **!** at the end of the type name indicates that we are looking for the class itself rather than instances of this class. - The second column is an access path that is evaluated from left to right, starting at the values that were identified by the first column. - + - **Call** selects calls to the class. That is, constructor calls. - **Argument[0,upload_to:]** selects the first positional argument, or the named argument named **upload_to**. Note that the colon at the end of the argument name indicates that we are looking for a named argument. - **Parameter[1]** selects the second parameter of the callback function, which is the parameter receiving the filename. From 8ab0a5b4dfaa120328220e7d05e485f989d6c460 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Fri, 20 Mar 2026 14:59:38 +0000 Subject: [PATCH 2/5] (Formatting) Remove erroneous bullet point in ruby docs --- .../customizing-library-models-for-ruby.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 23a6bd419f5d..246f77db8434 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -182,7 +182,7 @@ We can model this using the following data extension: - Since we're adding flow through a method call, we add a tuple to the **summaryModel** extensible predicate. - The first column, **"URI!"**, begins the search for relevant calls at references to the **URI** class. -- The **!** suffix indicates that we are looking for the class itself, rather than instances of the class. + The **!** suffix indicates that we are looking for the class itself, rather than instances of the class. - The second column, **Method[decode_uri_component]**, is a path leading to the method calls we wish to model. In this case, we select references to the **decode_uri_component** method from the **URI** class. - The third column, **Argument[0]**, indicates the input of the flow. In this case, the first argument to the method call. From 7fab0b6693447868226c5be3ce184ee782e35edb Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Sat, 21 Feb 2026 23:12:21 +0000 Subject: [PATCH 3/5] List extensible predicates for barriers and barrier guards --- .../customizing-library-models-for-cpp.rst | 2 ++ .../customizing-library-models-for-csharp.rst | 2 ++ .../customizing-library-models-for-go.rst | 2 ++ .../customizing-library-models-for-java-and-kotlin.rst | 2 ++ .../customizing-library-models-for-javascript.rst | 2 ++ .../customizing-library-models-for-python.rst | 2 ++ .../customizing-library-models-for-ruby.rst | 2 ++ 7 files changed, 14 insertions(+) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index 29e8be5a4ae4..1fd14d9d6f87 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -58,6 +58,8 @@ The CodeQL library for CPP analysis exposes the following extensible predicates: - ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index 39b5ee30ee47..355a521e9109 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -58,6 +58,8 @@ The CodeQL library for C# analysis exposes the following extensible predicates: - ``sourceModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(namespace, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(namespace, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(namespace, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 946ee1937b45..8bee130ddc27 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -58,6 +58,8 @@ The CodeQL library for Go analysis exposes the following extensible predicates: - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data may be used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) can be used to override generated summary models (those with a provenance such as ``df-generated``), so that the summary model will be ignored. Other than that, neutral models have no effect. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index 7f0a41b3040e..dafd0213b872 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -63,6 +63,8 @@ The CodeQL library for Java and Kotlin analysis exposes the following extensible - ``sourceModel(package, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model sources of potentially tainted data. The ``kind`` of the sources defined using this predicate determine which threat model they are associated with. Different threat models can be used to customize the sources used in an analysis. For more information, see ":ref:`Threat models `." - ``sinkModel(package, type, subtypes, name, signature, ext, input, kind, provenance)``. This is used to model sinks where tainted data maybe used in a way that makes the code vulnerable. - ``summaryModel(package, type, subtypes, name, signature, ext, input, output, kind, provenance)``. This is used to model flow through elements. +- ``barrierModel(namespace, type, subtypes, name, signature, ext, output, kind, provenance)``. This is used to model barriers, which are elements that stop the flow of taint. +- ``barrierGuardModel(namespace, type, boolean subtypes, name, signature, ext, input, acceptingvalue, kind, provenance)``. This is used to model barrier guards, which are elements that can stop the flow of taint depending on a conditional check. - ``neutralModel(package, type, name, signature, kind, provenance)``. This is similar to a summary model but used to model the flow of values that have only a minor impact on the dataflow analysis. Manual neutral models (those with a provenance such as ``manual`` or ``ai-manual``) override generated summary models (those with a provenance such as ``df-generated``) so that the summary will be ignored. Other than that, neutral models have a slight impact on the dataflow dispatch logic, which is out of scope for this documentation. The extensible predicates are populated using the models defined in data extension files. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst index b8f064c75747..7fea38b05c20 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst @@ -26,6 +26,8 @@ The CodeQL library for JavaScript exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 69e6355e2096..9fdefa696b84 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -26,6 +26,8 @@ The CodeQL library for Python exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 246f77db8434..227a178bf8e9 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -27,6 +27,8 @@ The CodeQL library for Ruby exposes the following extensible predicates: - **sinkModel**\(type, path, kind) - **typeModel**\(type1, type2, path) - **summaryModel**\(type, path, input, output, kind) +- **barrierModel**\(type, path, kind) +- **barrierGuardModel**\(type, path, branch, kind) We'll explain how to use these using a few examples, and provide some reference material at the end of this article. From d12eaff9ef71f6e544a9404d1eda28fd51d8ba82 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Tue, 20 Jan 2026 14:40:44 +0000 Subject: [PATCH 4/5] Update docs for barriers and barrier guards --- .../customizing-library-models-for-cpp.rst | 82 ++++++++++++++++++ .../customizing-library-models-for-csharp.rst | 84 ++++++++++++++++++ .../customizing-library-models-for-go.rst | 82 ++++++++++++++++++ ...ing-library-models-for-java-and-kotlin.rst | 85 +++++++++++++++++++ ...tomizing-library-models-for-javascript.rst | 55 ++++++++++++ .../customizing-library-models-for-python.rst | 60 +++++++++++++ .../customizing-library-models-for-ruby.rst | 59 +++++++++++++ 7 files changed, 507 insertions(+) diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst index 1fd14d9d6f87..a96fd6ea352f 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-cpp.rst @@ -178,6 +178,88 @@ The remaining values are used to define the input and output specifications, the - The ninth value ``"taint"`` is the kind of the flow. ``taint`` means that taint is propagated through the call. - The tenth value ``"manual"`` is the provenance of the summary, which is used to identify the origin of the summary model. +Example: Taint barrier using the ``mysql_real_escape_string`` function +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This example shows how the CPP query pack models the ``mysql_real_escape_string`` function as a barrier for SQL injection. +This function escapes special characters in a string for use in an SQL statement, which prevents SQL injection attacks. + +.. code-block:: cpp + + char *query = "SELECT * FROM users WHERE name = '%s'"; + char *name = get_untrusted_input(); + char *escaped_name = new char[2 * strlen(name) + 1]; + mysql_real_escape_string(mysql, escaped_name, name, strlen(name)); // The escaped_name is safe for SQL injection. + sprintf(query_buffer, query, escaped_name); + +We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/cpp-all + extensible: barrierModel + data: + - ["", "", False, "mysql_real_escape_string", "", "", "Argument[*1]", "sql-injection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case a free function) to be modeled as a barrier. + +- The first value ``""`` is the namespace name. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The third value ``False`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. For a free function, this should be ``False``. +- The fourth value ``"mysql_real_escape_string"`` is the function name. +- The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the output specification, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``"Argument[*1]"`` is the output specification, which means in this case that the barrier is the first indirection (or pointed-to value, ``*``) of the second argument (``Argument[1]``) passed to the function. +- The eighth value ``"sql-injection"`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. +- The ninth value ``"manual"`` is the provenance of the barrier, which is used to identify the origin of the barrier model. + +Example: Add a barrier guard +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider a function called ``is_safe`` which returns ``true`` when the data is considered safe. + +.. code-block:: cpp + + if (is_safe(user_input)) { // The check guards the use, so the input is safe. + mysql_query(user_input); // This is safe. + } + +We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/cpp-all + extensible: barrierGuardModel + data: + - ["", "", False, "is_safe", "", "", "Argument[*0]", "true", "sql-injection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case a free function) to be modeled as a barrier guard. + +- The first value ``""`` is the namespace name. +- The second value ``""`` is the name of the type (class) that contains the method. Because we're modelling a free function, the type is left blank. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. For a free function, this should be ``False``. +- The fourth value ``"is_safe"`` is the function name. +- The fifth value is the function input type signature, which can be used to narrow down between functions that have the same name. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the input specification, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[*0]`` is the input specification (the value being validated). In this case, the first indirection (or pointed-to value, ``*``) of the first argument (``Argument[0]``) passed to the function. +- The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The ninth value ``sql-injection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + .. _threat-models-cpp: Threat models diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst index 355a521e9109..bec5d55e95c5 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-csharp.rst @@ -309,6 +309,90 @@ For the remaining values for both rows: That is, the first row specifies that values can flow from the elements of the qualifier enumerable into the first argument of the function provided to ``Select``. The second row specifies that values can flow from the return value of the function to the elements of the enumerable returned from ``Select``. +Example: Add a barrier for the ``RawUrl`` property +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how we can model a property as a barrier for a specific kind of query. +A barrier model is used to define that the flow of taint stops at the modeled element for the specified kind of query. +Here we model the getter of the ``RawUrl`` property of the ``HttpRequest`` class as a barrier for URL redirection queries. +The ``RawUrl`` property returns the raw URL of the current request, which is considered safe for URL redirects because it is the URL of the current request and cannot be manipulated by an attacker. + +.. code-block:: csharp + + public static void TaintBarrier(HttpRequest request) { + string url = request.RawUrl; // The return value of this property is considered safe for URL redirects. + Response.Redirect(url); // This is not a URL redirection vulnerability. + } + +We need to add a tuple to the ``barrierModel``\(namespace, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/csharp-all + extensible: barrierModel + data: + - ["System.Web", "HttpRequest", False, "get_RawUrl", "()", "", "ReturnValue", "url-redirection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case the getter of a property) to be modeled as a barrier. + +- The first value ``System.Web`` is the namespace name. +- The second value ``HttpRequest`` is the class (type) name. +- The third value ``False`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. +- The fourth value ``get_RawUrl`` is the method name. Getter and setter methods are named ``get_`` and ``set_`` respectively. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the return value of the property getter, which means that the return value is considered safe. +- The eighth value ``url-redirection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the URL redirection queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Add a barrier guard for the ``IsAbsoluteUri`` property +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how we can model a property as a barrier guard for a specific kind of query. +A barrier guard model is used to stop the flow of taint when a conditional check is performed on data. +Here we model the getter of the ``IsAbsoluteUri`` property of the ``Uri`` class as a barrier guard for URL redirection queries. +When the ``IsAbsoluteUri`` property returns ``false``, the URL is relative and therefore safe for URL redirects because it cannot redirect to an external site controlled by an attacker. + +.. code-block:: csharp + + public static void TaintBarrierGuard(Uri uri) { + if (!uri.IsAbsoluteUri) { // The check guards the redirect, so the URL is safe. + Response.Redirect(uri.ToString()); // This is not a URL redirection vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(namespace, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/csharp-all + extensible: barrierGuardModel + data: + - ["System", "Uri", False, "get_IsAbsoluteUri", "()", "", "Argument[this]", "false", "url-redirection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case the getter of a property) to be modeled as a barrier guard. + +- The first value ``System`` is the namespace name. +- The second value ``Uri`` is the class (type) name. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. +- The fourth value ``get_IsAbsoluteUri`` is the method name. Getter and setter methods are named ``get_`` and ``set_`` respectively. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the property access (``uri`` in the example). +- The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsAbsoluteUri`` is ``false``, the URL is relative and considered safe. +- The ninth value ``url-redirection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the URL redirection queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Add a ``neutral`` method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how we can model a method as being neutral with respect to flow. We will also cover how to model a property by modeling the getter of the ``Now`` property of the ``DateTime`` class as neutral. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst index 8bee130ddc27..cfa87f2f7366 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-go.rst @@ -341,6 +341,88 @@ The remaining values are used to define the ``access path``, the ``kind``, and t - The ninth value ``taint`` is the kind of the flow. ``taint`` means that taint is propagated through the call. - The tenth value ``manual`` is the provenance of the summary, which is used to identify the origin of the summary. +Example: Add a barrier using the ``Htmlquote`` function +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Go query pack models a barrier that stops the flow of taint. +The ``Htmlquote`` function from the beego framework HTML-escapes a string, which prevents HTML injection attacks. + +.. code-block:: go + + func Render(w http.ResponseWriter, r *http.Request) { + name := r.FormValue("name") + safe := beego.Htmlquote(name) // The return value of this function is safe to use in HTML. + ... + } + +We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/go-all + extensible: barrierModel + data: + - ["group:beego", "", True, "Htmlquote", "", "", "ReturnValue", "html-injection", "manual"] + +Since we are adding a barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the function to be modeled as a barrier. + +- The first value ``group:beego`` is the package group name. The ``group:`` prefix indicates that this is a package group, which is used to match multiple package paths that refer to the same package. +- The second value ``""`` is left blank since the function is not a method of a type. +- The third value ``True`` is a flag that indicates whether or not the barrier also applies to subtypes. This has no effect for non-method functions. +- The fourth value ``Htmlquote`` is the function name. +- The fifth value ``""`` is the input type signature. For Go it should always be an empty string. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the output of the barrier, which means that the return value is considered sanitized. +- The eighth value ``html-injection`` is the kind of the barrier. The barrier kind must match the kind used in the query where the barrier should take effect. In this case, it matches the ``html-injection`` sink kind used by XSS queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Add a barrier guard +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider a function called ``IsSafe`` which returns ``true`` when the data is considered safe for SQL injection. + +.. code-block:: go + + func Query(db *sql.DB, input string) { + if example.IsSafe(input) { // The check guards the query, so the input is safe. + db.Query(input) // This is not a SQL injection vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/go-all + extensible: barrierGuardModel + data: + - ["example.com/example", "", False, "IsSafe", "", "", "Argument[0]", "true", "sql-injection", "manual"] + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the function to be modeled as a barrier guard. + +- The first value ``example.com/example`` is the package name. +- The second value ``""`` is left blank since the function is not a method of a type. +- The third value ``False`` is a flag that indicates whether or not the barrier guard also applies to subtypes. This has no effect for non-method functions. +- The fourth value ``IsSafe`` is the function name. +- The fifth value ``""`` is the input type signature. For Go it should always be an empty string. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[0]`` is the access path to the input whose flow is blocked. In this case, the first argument to the function (``input`` in the example). +- The eighth value ``true`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``IsSafe`` returns ``true``, the input is considered safe. +- The ninth value ``sql-injection`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the SQL injection queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Accessing the ``Body`` field of an HTTP request ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how we can model a field read as a source of tainted data. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst index dafd0213b872..3cd67022a822 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-java-and-kotlin.rst @@ -259,6 +259,91 @@ For the remaining values for both rows: That is, the first row specifies that values can flow from the elements of the qualifier stream into the first argument of the function provided to ``map``. The second row specifies that values can flow from the return value of the function to the elements of the stream returned from ``map``. +Example: Taint barrier in the ``java.io`` package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Java query pack models the return value from the ``getName`` method as a barrier for path injection. +This is the ``getName`` method in the ``File`` class, which is located in the ``java.io`` package. The method returns only the final component of a path, which means that it protects against path injection vulnerabilities. + +.. code-block:: java + + public static void barrier(File file) { + String name = file.getName(); // The return value of this method is a barrier for path injection. + ... + } + +We need to add a tuple to the ``barrierModel``\(package, type, subtypes, name, signature, ext, output, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/java-all + extensible: barrierModel + data: + - ["java.io", "File", True, "getName", "()", "", "ReturnValue", "path-injection", "manual"] + + +Since we are adding a new barrier, we need to add a tuple to the ``barrierModel`` extensible predicate. +The first five values identify the callable (in this case a method) to be modeled as a barrier. + +- The first value ``java.io`` is the package name. +- The second value ``File`` is the name of the class (type) that contains the method. +- The third value ``True`` is a flag that indicates whether or not the barrier also applies to all overrides of the method. +- The fourth value ``getName`` is the method name. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``kind``, and the ``provenance`` (origin) of the barrier. + +- The seventh value ``ReturnValue`` is the access path to the return of the method, which means that it is the return value that should be considered a barrier. +- The eighth value ``path-injection`` is the kind of the barrier. The barrier kind is used to define the queries where the barrier is in scope. In this case - the path injection queries. +- The ninth value ``manual`` is the provenance of the barrier, which is used to identify the origin of the barrier. + +Example: Taint barrier guard in the ``java.net`` package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This example shows how the Java query pack models the ``isAbsolute`` method as a barrier guard for request forgery. +This is the ``isAbsolute`` method in the ``URI`` class, which is located in the ``java.net`` package. +A barrier guard model is used to stop the flow of taint when a conditional check is performed on data. +When the ``isAbsolute`` method returns ``false``, the URI is relative and therefore safe for request forgery because it cannot redirect to an external server controlled by an attacker. + +.. code-block:: java + + public static void barrierguard(URI uri) throws IOException { + if (!uri.isAbsolute()) { // The check guards the request, so the URI is safe. + URL url = uri.toURL(); + url.openConnection(); // This is not a request forgery vulnerability. + } + } + +We need to add a tuple to the ``barrierGuardModel``\(package, type, subtypes, name, signature, ext, input, acceptingvalue, kind, provenance) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/java-all + extensible: barrierGuardModel + data: + - ["java.net", "URI", True, "isAbsolute", "()", "", "Argument[this]", "false", "request-forgery", "manual"] + + +Since we are adding a barrier guard, we need to add a tuple to the ``barrierGuardModel`` extensible predicate. +The first five values identify the callable (in this case a method) to be modeled as a barrier guard. + +- The first value ``java.net`` is the package name. +- The second value ``URI`` is the name of the class (type) that contains the method. +- The third value ``True`` is a flag that indicates whether or not the barrier guard also applies to all overrides of the method. +- The fourth value ``isAbsolute`` is the method name. +- The fifth value ``()`` is the method input type signature. + +The sixth value should be left empty and is out of scope for this documentation. +The remaining values are used to define the ``access path``, the ``accepting value``, the ``kind``, and the ``provenance`` (origin) of the barrier guard. + +- The seventh value ``Argument[this]`` is the access path to the input whose flow is blocked. In this case, the qualifier of the method call (``uri`` in the example). +- The eighth value ``false`` is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. In this case, when ``isAbsolute`` is ``false``, the URI is relative and considered safe. +- The ninth value ``request-forgery`` is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. In this case - the request forgery queries. +- The tenth value ``manual`` is the provenance of the barrier guard, which is used to identify the origin of the barrier guard. + Example: Add a ``neutral`` method ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This example shows how the Java query pack models the ``now`` method as being neutral with respect to flow. diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst index 7fea38b05c20..95119d117456 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-javascript.rst @@ -393,6 +393,61 @@ This can be achieved with the following data extension: - **Member[data]** selects accesses to the **data** property of the **req** object. - Finally, the kind **remote** indicates that this is considered a source of remote flow. +Example: Taint barrier using the 'encodeURIComponent' function +-------------------------------------------------------------- + +In this example, we'll show how to add the return value of **encodeURIComponent** as a barrier for XSS. + +.. code-block:: js + + let escaped = encodeURIComponent(input); // The return value of this method is safe for XSS. + document.body.innerHTML = escaped; + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/javascript-all + extensible: barrierModel + data: + - ["global", "Member[encodeURIComponent].ReturnValue", "html-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"global"**, begins the search for relevant calls at references to the global object. +- The second column, **Member[encodeURIComponent].ReturnValue**, selects the return value of the **encodeURIComponent** function. +- The third column, **"html-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +Consider a function called `isValid` which returns `true` when the data is considered safe. + +.. code-block:: js + + if (isValid(userInput)) { // The check guards the use, so the input is safe. + db.query(userInput); // This is safe. + } + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/javascript-all + extensible: barrierGuardModel + data: + - ["my-package", "Member[isValid].Argument[0]", "true", "sql-injection"] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"my-package"**, begins the search at imports of the hypothetical NPM package **my-package**. +- The second column, **Member[isValid].Argument[0]**, selects the first argument of the `isValid` function. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"sql-injection"**, is the kind of the barrier guard. + Reference material ------------------ diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst index 9fdefa696b84..54b1023c7d09 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-python.rst @@ -281,6 +281,66 @@ We might also provide a summary stating that the elements of the input list are The tracking of list elements is imprecise in that the analysis does not know where in the list the tracked value is found. So this summary simply states that if the value is found somewhere in the input list, it will also be found somewhere in the output list, unchanged. +Example: Taint barrier using the 'escape' function +-------------------------------------------------- + +In this example, we'll show how to add the return value of **html.escape** as a barrier for XSS. + +.. code-block:: python + + import html + escaped = html.escape(unknown) # The return value of this function is safe for XSS. + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/python-all + extensible: barrierModel + data: + - ["html", "Member[escape].ReturnValue", "html-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"html"**, begins the search at places where the **html** module is imported. +- The second column, **Member[escape].ReturnValue**, selects the return value of the **escape** function from the **html** module. +- The third column, **"html-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +A barrier guard model is used when a function returns a boolean that indicates whether the data is safe to use. +Consider the function ``url_has_allowed_host_and_scheme`` from the ``django.utils.http`` package which returns ``true`` when the URL is in a safe domain. + +.. code-block:: python + + if url_has_allowed_host_and_scheme(url, allowed_hosts=...): # The check guards the use of 'url', so it is safe. + redirect(url) # This is safe. + +We need to add a tuple to the ``barrierGuardModel``\(type, path, branch, kind, madId) extensible predicate by updating a data extension file. + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/python-all + extensible: barrierGuardModel + data: + - [ + "django", + "Member[utils].Member[http].Member[url_has_allowed_host_and_scheme].Argument[0,url:]", + "true", + "url-redirection", + ] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"django"**, begins the search at places where the **django** package is imported. +- The second column, **Member[utils].Member[http].Member[url_has_allowed_host_and_scheme].Argument[0,url:]**, selects the first argument (or the keyword argument ``url``) of the ``url_has_allowed_host_and_scheme`` function in the ``django.utils.http`` module. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"url-redirection"**, is the kind of the barrier guard. The barrier guard kind is used to define the queries where the barrier guard is in scope. + Reference material ------------------ diff --git a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst index 227a178bf8e9..37636960fe85 100644 --- a/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst +++ b/docs/codeql/codeql-language-guides/customizing-library-models-for-ruby.rst @@ -232,6 +232,65 @@ We can model this using the following data extension: - The last column, **taint**, indicates the kind of flow to add. +Example: Taint barrier using the 'escape' method +------------------------------------------------ + +In this example, we'll show how to add the return value of **Mysql2::Client#escape** as a barrier for SQL injection. + +.. code-block:: ruby + + client = Mysql2::Client.new + escaped = client.escape(input) # The return value of this method is safe for SQL injection. + client.query("SELECT * FROM users WHERE name = '#{escaped}'") + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/ruby-all + extensible: barrierModel + data: + - ["Mysql2::Client!", "Method[escape].ReturnValue", "sql-injection"] + +- Since we are adding a barrier, we need to add a tuple to the **barrierModel** extensible predicate. +- The first column, **"Mysql2::Client!"**, begins the search for relevant calls at references to the **Mysql2::Client** class. + The **!** suffix indicates that we want to search for references to the class itself, rather than instances of the class. +- The second column, **"Method[escape].ReturnValue"**, selects the return value of the **escape** method. +- The third column, **"sql-injection"**, is the kind of the barrier. + +Example: Add a barrier guard +---------------------------- + +This example shows how to model a barrier guard that stops the flow of taint when a conditional check is performed on data. +Consider a validation method ``Validator.is_safe`` which returns ``true`` when the data is considered safe. + +.. code-block:: ruby + + if Validator.is_safe(user_input) + # The check guards the use, so the input is safe. + client.query("SELECT * FROM users WHERE name = '#{user_input}'") + end + +We can model this using the following data extension: + +.. code-block:: yaml + + extensions: + - addsTo: + pack: codeql/ruby-all + extensible: barrierGuardModel + data: + - ["Validator!", "Method[is_safe].Argument[0]", "true", "sql-injection"] + +- Since we are adding a barrier guard, we need to add a tuple to the **barrierGuardModel** extensible predicate. +- The first column, **"Validator!"**, begins the search at references to the **Validator** class. + The **!** suffix indicates that we want to search for references to the class itself, rather than instances of the class. +- The second column, **"Method[is_safe].Argument[0]"**, selects the first argument of the **is_safe** method. This is the value being validated. +- The third column, **"true"**, is the accepting value of the barrier guard. This is the value that the conditional check must return for the barrier to apply. +- The fourth column, **"sql-injection"**, is the kind of the barrier guard. + Reference material ------------------ From 0eb69f3afeb20c81e3388d063c6231ecd4d9cb31 Mon Sep 17 00:00:00 2001 From: Owen Mansel-Chan Date: Fri, 20 Mar 2026 15:22:29 +0000 Subject: [PATCH 5/5] Add change notes --- .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ .../lib/change-notes/2026-03-20-data-extensions-barriers.md | 4 ++++ 8 files changed, 32 insertions(+) create mode 100644 cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md create mode 100644 rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md diff --git a/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..281008e46971 --- /dev/null +++ b/cpp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C and C++ `__. diff --git a/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..4d5cc0c0d0d4 --- /dev/null +++ b/csharp/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for C# `__. diff --git a/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..1e86b59d5b57 --- /dev/null +++ b/go/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Go `__. diff --git a/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..d4ae1f8711d4 --- /dev/null +++ b/java/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Java and Kotlin `__. diff --git a/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..e8bacba89b14 --- /dev/null +++ b/javascript/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for JavaScript `__. diff --git a/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..b33a89ba7765 --- /dev/null +++ b/python/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Python `__. diff --git a/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..fecf79a0de78 --- /dev/null +++ b/ruby/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions. For more information see `Customizing library models for Ruby `__. diff --git a/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md b/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md new file mode 100644 index 000000000000..5e97a1533a9e --- /dev/null +++ b/rust/ql/lib/change-notes/2026-03-20-data-extensions-barriers.md @@ -0,0 +1,4 @@ +--- +category: feature +--- +* Data flow barriers and barrier guards can now be added using data extensions.