---
title: "Secure database access"
manual: "TYPO3 Explained"
version: "13.4"
permalink: "https://docs.typo3.org/permalink/t3coreapi:security-database-access@13.4"
source: "Security/GuidelinesAdministrators/DatabaseAccess.rst"
rendered: "2026-09-18T05:52:58+00:00"
---

# Secure database access {#secure-database-access}

The TYPO3 database stores all user data (both backend and frontend), along with
critical configuration and content. It is essential to protect this data from
unauthorized access.

These recommendations apply to both self-managed and shared hosting environments.

If you are using managed or shared hosting, you may not be responsible for
configuring the database yourself. However, it is still important to ensure
that your TYPO3 installation uses a dedicated database user with limited
permissions. If you are unsure, ask your hosting provider whether the database
user has access only to your TYPO3 database and is restricted to the minimum
required privileges.

**Table of contents**

-   [Do not store credentials in version control](https://docs.typo3.org/permalink/t3coreapi:do-not-store-credentials-in-version-control@13.4)
-   [Use strong passwords and limit privileges](https://docs.typo3.org/permalink/t3coreapi:use-strong-passwords-and-limit-privileges@13.4)
-   [Keep SQLite files out of the web root](https://docs.typo3.org/permalink/t3coreapi:keep-sqlite-files-out-of-the-web-root@13.4)
-   [Restrict database server access](https://docs.typo3.org/permalink/t3coreapi:restrict-database-server-access@13.4)
-   [Avoid web-based database tools in production](https://docs.typo3.org/permalink/t3coreapi:avoid-web-based-database-tools-in-production@13.4)

## Do not store credentials in version control {#do-not-store-credentials-in-version-control}

Database credentials and other sensitive information should never be stored in
Git or any other version control system.

For example, do not commit files such as:

-   `.env`
-   `config/system/settings.php` (if it contains credentials directly)

Exposing credentials publicly, or even within internal team repositories,
creates unnecessary risk.

**Recommendation:** Use environment-specific configuration and exclude
credential files from version control using mechanisms like `.gitignore`.

For more information and best practices, see:
[Avoid storing credentials in version control](https://docs.typo3.org/permalink/t3coreapi:version-control-credentials@13.4).

## Use strong passwords and limit privileges {#use-strong-passwords-and-limit-privileges}

When using MySQL, database users must authenticate before connecting.
Permissions are granted at various levels (for example, per database,
per table, or per action such as SELECT or INSERT).

**Best practices:**

-   Use a secure password for the TYPO3 database user. See
    [secure password guidelines](https://docs.typo3.org/permalink/t3coreapi:security-secure-passwords@13.4).
-   Do **not** use obvious usernames like `root`, `admin`, or `typo3`.
-   Create a dedicated user with **access only to the TYPO3 database**, and only
    with the permissions it requires (SELECT, INSERT, UPDATE, DELETE, etc.).
-   Avoid granting administrative privileges such as `LOCK TABLES`, `FILE`,
    `PROCESS`, `RELOAD`, or `SHUTDOWN` unless absolutely necessary.

## Keep SQLite files out of the web root {#keep-sqlite-files-out-of-the-web-root}

SQLite stores the database in a single file. By default, TYPO3 places this file
in the [var/sqlite](https://docs.typo3.org/permalink/t3coreapi:environment-var-path@13.4) directory, derived from the
`TYPO3_PATH_APP` environment variable.

**Warning:** In non-Composer installations, if `TYPO3_PATH_APP` is not set,
the SQLite file may be created in `typo3conf/`, which is inside the web
server's document root and publicly accessible.

If you are using SQLite:

-   Ensure that `.sqlite` files are **not accessible via the web server**
-   Move the database file outside of the document root if possible

## Restrict database server access {#restrict-database-server-access}

The database server should only accept connections from the TYPO3 application
host. It must never be exposed to the public internet.

**Recommended actions:**

-   Configure firewalls to block external access to the database port
-   Ensure the database server is bound only to `localhost` or a private network
-   For MySQL, review the options `skip-networking` and `bind-address` in the
    official documentation:
    [MySQL Server Options](https://dev.mysql.com/doc/refman/8.0/en/server-option-variable-reference.html)

## Avoid web-based database tools in production {#avoid-web-based-database-tools-in-production}

Tools like `phpMyAdmin` provide web access to the database for administrative
tasks. While sometimes helpful during development, they increase the attack
surface in production environments.

If such tools must be used:

-   Protect them with additional access controls, such as HTTP authentication
    (for example, Apache `.htaccess`)
-   Keep them updated to patch known vulnerabilities

For local development or secure remote access, prefer standalone database
clients such as [HeidiSQL](https://www.heidisql.com/), [DBeaver](https://dbeaver.io/),
or [MySQL Workbench](https://www.mysql.com/products/workbench/). These tools
connect directly to the database server and do not expose a web interface,
reducing the attack surface.

**Recommendation:** Do not use phpMyAdmin or similar tools on live TYPO3 sites.
All regular access to the database should be managed through TYPO3 or CLI tools.