No. The Spring Boot docs say the H2 console is only intended for development, and that spring.h2.console.enabled must not be true in production. The console also uses frames and does not implement CSRF protection. Treat any production instance that exposes it as a serious misconfiguration.
What the console is
H2 is an embedded database often used for local work and tests. It ships a browser based console for running SQL. Spring Boot can auto configure it. A tool that can run SQL against your data is powerful, which is why it must not be reachable by unauthorised users.
How it becomes enabled
The Spring Boot docs say the console is auto configured when all of these are true: you are building a servlet based web application, the H2 console module is on the classpath, and you are using Spring Boot's developer tools. You can also enable it directly with the spring.h2.console.enabled property. By default it is served at the path h2-console, and spring.h2.console.path changes that.
| Trigger | Where it comes from |
|---|---|
| Devtools plus console module | Auto configuration |
| spring.h2.console.enabled set to true | Explicit setting, possibly copied into a shared profile |
| Custom path | spring.h2.console.path |
Why a secured app needs extra care
The docs explain that because the console uses frames and has no CSRF protection, an app using Spring Security must disable CSRF for console requests and set X-Frame-Options to SAMEORIGIN for its responses. Teams often do this globally, which weakens the whole application. If you must do it, scope it to a development profile and a dedicated chain.
Steps to check production
- Search all configuration files and profiles for the enabled property and the path property.
- Confirm the H2 database and console modules are not in the production dependency tree. Use dependency inspection.
- Request the console path against a staging copy of production and expect a not found response.
- Remove any CSRF exception or frame option exception that exists only for the console.
- Use a real database for production. Embedded test databases belong in test scope.
- Add a regression test that asserts the path is not served.
Past advisories show why this matters. See our write up of an H2 console remote code execution issue.
A worked example
A team builds a prototype with H2 and the console, and enables it with a property in the main configuration file because it was quicker than a profile. The prototype becomes a real service. Months later the same file ships to production, with a real database URL added in an environment variable. The console path is still served, and CSRF exceptions added for it are still in the security chain.
The lesson is that development switches need an owner and an expiry. Put them in a development profile, and fail the build if they appear in production configuration.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Is the console on if I do not use devtools?
Only if you enable it with the property. Without devtools the auto configuration condition is not met.
Can I change the path to hide it?
You can, but obscurity is not protection. Disable it in production.
Sources
Last reviewed: 19 October 2026.
