Revision control
Copy as Markdown
// Copyright (C) 2026 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
/*!
\page shared-security-model.html
\title Qt Shared Security Model
\brief Understanding security responsibilities in Qt applications.
\ingroup security
The Qt Shared Security Model defines the distribution of security
responsibilities among Qt application developers, the Qt Group and
Qt Project as providers of the Qt Framework, and operators or device
manufacturers.
The model establishes clear expectations regarding responsibility for
security across the various layers of the technology stack in a typical
Qt application or device.
This page provides guidance for developers building Qt applications and for
security researchers reporting security issues in Qt.
\section1 Overview
Security in Qt applications is a shared responsibility. Qt provides secure
frameworks and libraries, but the ultimate security of an application
depends on how developers use these components and how they handle
application-specific concerns.
A typical Qt application can be visualized as a stack:
\image {shared-security-model.svg}{Layers of responsibility: App, Qt, Process, OS,
Hardware}
\section1 Roles and responsibilities
\section2 Responsibilities of the application developer
You, as an application developer, are responsible for the security of the
application-specific code, assets, and configuration. You also assume
responsibility for any standalone third-party libraries that are shipped
with the application.
Qt aims to provide a user-friendly, safe-by-default API. However, it is your
responsibility to use the API diligently, and for example check for error
conditions and handle them appropriately. For an overview of security
considerations when using Qt, see \l{Security in Qt}.
Review your application in terms of which data sources are trusted and which
are untrusted. Make sure to validate and sanitize untrusted data using
appropriate Qt APIs. See also \l{Handling Untrusted Data} for more information.
Plan mechanisms to update the application and apply Qt security updates in a
timely manner. Follow Qt releases and security announcements, and update Qt
accordingly. Also, ensure that you obtain Qt from a trusted source.
The same applies to the projects you build. Qt's developer tools run on your
build machine and treat the project they process as trusted input, so only
build projects from sources you trust. For more information, see
\l{Using Qt's Developer Tools Securely}.
If you ship Qt as part of your application, limit the number of libraries
and plugins to reduce the attack surface. For example, ship only the image
plugins for the formats you actually need.
When switching Qt defaults, be careful that you don't accidentally disable
security features or weaken security guarantees. For example, don't disable
SSL/TLS certificate validation unless you have a very good reason to do so.
Another example is changes to the Qt search paths, for instance through
\l{qt.conf}. Make sure all paths are trustworthy.
\section2 Responsibilities of Qt
The Qt Group and Qt Project are responsible for the security of the Qt
framework itself, including all
officially distributed binaries and redistributables. This includes
maintaining and updating any third-party components bundled with Qt
libraries and plugins, tracking known vulnerabilities, and providing timely
fixes.
Qt aims to provide APIs that are secure by default. Common use cases are
designed to minimize the risk of misuse, while operations with security
implications require explicit developer action.
Qt provides APIs a developer can use to process and validate
\l{Untrusted data}{data from untrusted sources}, such as user input, network
communication, or external files. Where it is unreasonable for a developer
to implement their own validation, Qt provides built-in validation.
For example, Qt's image decoders are designed to securely parse
image files. There might be APIs though where neither is possible or
reasonable; in these cases, the documentation warns about calling the API
with untrusted data.
\section2 Responsibilities of operator or device manufacturer
Both Qt and the application have to rely on the security and integrity of
the operating environment (hardware, operating system, and
services). On desktop systems, this
is typically the responsibility of the operator of the application;
for example, by keeping the operating system up-to-date.
On embedded devices, it is the responsibility of the device manufacturer.
This includes the \e{process environment} that the Qt application is running
in. For instance, all desktop applications expect the directories in the
\c{PATH} environment variable to be trustworthy.
\section3 Assumptions
Qt's security guarantees and the acceptance criteria below rely on the
following baseline assumptions about the environment in which a Qt
application runs. If any of these assumptions do not hold, the related
issues fall outside the intended purpose and supported conditions of use
on which Qt's cybersecurity risk assessment is based, and are therefore
not treated as vulnerabilities in Qt.
\list
\li \b{The attacker does not already control the device or
account}: Qt does not defend against an attacker who already has
physical or remote control of the device running the application,
or of the user account it runs under (for example, a stolen or
unlocked device, an open remote desktop session, or a compromised
account), independently of whether they can reach the application
process itself. The test is whether the attacker ends up with
privilege, access, or trust they did not already have. Where an
unprivileged local actor gains the application's privileges, or
influences it through data planted in a location the application
reads, a security boundary has been crossed and the issue is in
scope, even though the attack is local. See also
\l{Issues Qt will not accept}.
\li \b{The operating system and its environment are configured
correctly}: Qt assumes the OS, its configuration, and the process
environment (such as the \c{PATH} and \c{QT_PLUGIN_PATH} variables)
have not been tampered with or misconfigured. See
\l{Responsibilities of operator or device manufacturer}.
\li \b{Exposed hardware is genuine}: Qt assumes that hardware the
application interacts with (peripherals, sensors, or other attached
devices) is genuine and has not been substituted or physically
compromised. This does not extend to the data such hardware sends:
input received from external devices is untrusted input, and
defects reachable through it remain in scope. See
\l{Handling Untrusted Data}.
\endlist
\section1 Security issue acceptance criteria
Security researchers should use the following guidelines when determining
whether a potential security issue should be reported to the Qt Project:
\section2 Issues Qt will accept
The Qt Group and the Qt Project accept security issues that:
\list
\li \b{Affect Qt framework code}: Vulnerabilities in Qt's own code,
including memory corruption bugs, type confusion, use-after-free,
buffer overflows, and similar memory safety issues in Qt libraries.
\li \b{Affect bundled third-party components}: Security vulnerabilities
in third-party libraries and components that are bundled with Qt.
\li \b{Break security guarantees}: Issues where Qt APIs fail to provide
documented security guarantees or violate reasonable security
expectations for security-critical APIs.
\li \b{Affect default configurations}: Security issues in default Qt
configurations that could affect typical applications without
developer intervention.
\endlist
Qt also expects security issues to have a realistic attack scenario. Issues
that cannot be exploited in practice or require unrealistic conditions
will be treated as defects, but not considered security issues.
\section2 Issues Qt will not accept
The Qt Group and Qt Project do not accept reports for security issues that:
\list
\li \b{Require insecure application code}: Issues that only manifest
when the application developer writes insecure code or misuses Qt
APIs in ways that are not in line with documentation or established
best practices.
\li \b{Are based on application-specific logic flaws}: Security issues in
application-specific logic, such as authentication bypasses,
authorization flaws, or business logic vulnerabilities.
\li \b{Depend on malicious application code}: Issues that require the
application to execute malicious code. Qt assumes that application
developers control their own code and resources.
\li \b{Require malicious QML/JavaScript}: \l{Qt Qml} assumes all QML and
JavaScript code is provided by the application developer. Running
untrusted QML code is not supported. See \l{Handling Untrusted Data}
for more information.
\li \b{Depend on issues in operating environment}: Vulnerabilities in the
underlying operating system, hardware, or system libraries that are
not bundled with Qt.
\li \b{Depend on an insecure process environment}: Attacks that require
an insecure process environment, such as untrusted directories in the
\c{PATH} or \c{QT_PLUGIN_PATH} environment variables, are outside the
scope of Qt's security responsibility.
\li \b{Depend on private Qt headers}: Use of private headers is contrary
to the intended purpose of Qt and is not a supported configuration.
Weaknesses reachable only through the use of private headers fall
outside the intended purpose and supported conditions of use on which
Qt's cybersecurity risk assessment is based, and are therefore not
treated as vulnerabilities. We nonetheless welcome reports about
such weaknesses, as they may indicate opportunities to improve the
robustness of Qt.
\li \b{Don't affect Qt's libraries, plugins, or tools}:
Qt's autotests, and the infrastructure used to build and
release Qt, are not part of the product as deployed. Weaknesses
reachable only through them are not treated as vulnerabilities in
Qt. Build system files and tools that ship with Qt are in scope;
see \l{Using Qt's Developer Tools Securely}.
\li \b{Only affect example code}: Qt's examples illustrate API use and
are not intended for production use. Weaknesses in them are handled
as defects rather than vulnerabilities, but reports are welcome, as
examples are often copied into applications.
\endlist
Furthermore, reports for cybersecurity issues need a realistic attack scenario that
\list
\li \b{Crosses a security boundary}: an issue crosses a security
boundary when it gives the attacker privilege, access, or trust
they did not already hold. For example, issues which require an
attacker already having access to the application process and being able to
execute code are not considered security issues, because the
attacker already holds that access.
\li \b{Is not based on social engineering}: Issues that primarily rely on social
engineering or tricking users rather than technical vulnerabilities
in Qt.
\endlist
\section1 Frequently asked questions
\section2 Who is responsible for validating user input?
The application developer is responsible for validating user input.
While Qt provides validation tools (see \l{QValidator} and
\l{Qt Quick Text Input Handling and Validators}{QML Validators}), it is
the application's responsibility to use these tools appropriately and
implement application-specific validation logic.
\section2 Is Qt responsible for SQL injection vulnerabilities?
No. SQL injection vulnerabilities typically result from improper use of SQL
APIs. Developers must use parameterized queries and prepared statements
(such as \l{QSqlQuery::prepare}{QSqlQuery::prepare}) to prevent SQL
injection. However, Qt is responsible for ensuring that these secure APIs
function correctly.
\section2 What about cross-site scripting (XSS) in Qt applications?
XSS prevention is primarily the application developer's responsibility.
Developers must properly sanitize and escape data when displaying untrusted
content, especially in web views or rich text components. Qt provides APIs
like \l{QString::toHtmlEscaped} to assist with this, and \l{Qt WebEngine}
implements web platform security features, but the application must use
these correctly.
\section2 Who handles encryption and secure communications?
Both Qt and the application developer share responsibility:
\list
\li Qt provides secure networking APIs (\l{QSslSocket},
\l{QNetworkAccessManager}) with secure defaults.
\li Application developers must properly use these APIs, implement
certificate validation, manage keys securely, and handle sensitive
data appropriately. If they bundle OpenSSL with the application, it
is also their responsibility to keep it up to date and apply
security patches.
\endlist
\section2 Is loading untrusted QML code a security issue?
Running untrusted QML code is explicitly not supported and is considered a
misuse of the QML engine. \l{Qt Qml} is designed with the assumption that
all QML and JavaScript code is trusted and provided by the application
developer. If your application needs to load untrusted content, use
appropriate sandboxing mechanisms or alternative approaches, like a custom
Domain-Specific Language (DSL).
\section2 What about image file vulnerabilities?
Qt considers image decoding a security-critical API and takes responsibility
for securely parsing image files from untrusted sources. Security issues in
Qt's image decoders (buffer overflows, crashes, and similar issues) should be
reported to the Qt Group or Qt Project. However, applications must still
validate image sources, handle large images appropriately, and manage
application-specific image security concerns.
\section2 How do I report a security issue?
See \l{Reporting Security Issues} in the \l{Security in Qt} page for
detailed instructions on reporting security issues to the Qt Project.
\section2 What versions of Qt receive security updates?
Security updates are provided for supported Qt versions. See
\l{Qt Releases} for information about supported versions and
\l{Extended Security Maintenance} for end-of-support versions.
\section1 Additional Resources
For more information about security in Qt, see:
\list
\li \l{Security in Qt}
\li \l{Handling Untrusted Data}
\li \l{Application Permissions}
Qt Project Security Policy
{List of Known Vulnerabilities in Qt Products}
\endlist
*/