Prometheus Security Review
Prometheus has no built-in authentication, so anyone reaching its HTTP endpoint can read every metric it stores. We test that endpoint, the admin API, remote write and every exporter feeding it. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Two flags, –web.enable-admin-api and –web.enable-lifecycle, gate every administrative and lifecycle action on a Prometheus server, and Prometheus ships with both switched off by default.
A Prometheus server has no login screen of its own, so its protection depends entirely on what your team puts in front of it
Prometheus’s own security model presumes that anyone who can reach its HTTP endpoint is untrusted, and that person can read every stored time series plus a range of operational and debugging information, while only a smaller, trusted group can change the configuration file, rule files and command line. The same documentation states plainly that Prometheus’s HTTP endpoints, including the /metrics endpoint of instrumented binaries and the various server API endpoints, should not be exposed to a public network like the internet, and that doing so can also let the server be overloaded and effectively denied service. Two flags close the largest gaps in that default posture: –web.enable-admin-api exposes administrative functionality including time-series deletion under the /api/*/admin/ paths, and –web.enable-lifecycle exposes the /-/reload and /-/quit paths that reload configuration or stop the process over HTTP; Prometheus ships with both switched off.
The HTTP API’s PromQL query endpoints return whatever metrics the instance holds to any caller who can reach them, and Prometheus’s security documentation flags remote read as carrying the same exposure in the other direction: anyone with HTTP access can send queries to the remote read endpoint, and where those queries are evaluated directly against a backing store such as a relational database, anyone able to query Prometheus this way can run arbitrary queries against that store. The remote_write configuration block sends every scraped sample onward and authenticates that outbound connection however the operator configures it: Prometheus’s configuration reference lists basic auth, a bearer token, OAuth2, AWS SigV4 (the scheme Amazon Managed Service for Prometheus expects) and Azure AD as mutually exclusive options, none of which applies unless it is explicitly set. We test what the query API, remote write and remote read endpoints actually return or accept from a caller with nothing more than network access.
Prometheus has no concept of users, roles or organisations anywhere in its own product, a sharp contrast with Grafana, the tool Prometheus is overwhelmingly deployed to feed, which layers organisations, Viewer, Editor and Admin roles and, in Enterprise or Cloud, data source permissions on top of every data source it queries, Prometheus included. Grafana’s own documentation confirms its data source proxy runs queries with the data source’s own configured credentials rather than the viewer’s, so Grafana’s role model narrows what a person sees on a dashboard without narrowing what Prometheus itself will answer for anyone who reaches it directly. We review the reverse proxy, firewall rules, web.yml authentication, exporter exposure and remote endpoint configuration on your own Prometheus instance, the same way we review configuration on a database platform rather than the database engine itself; we never test Prometheus’s own codebase or attempt to find vulnerabilities in the open-source project.
SCOPE
What we review in a Prometheus instance
No Built-in Authentication or Encryption
Prometheus ships with no authentication, authorisation or encryption of its own: its documented security model presumes that anyone who can reach the HTTP endpoint is untrusted, and that person can read every stored time series plus a range of operational and debugging information. The same documentation is explicit that Prometheus’s HTTP endpoints, including the expression browser and the API, should not be exposed to a public network like the internet, and that doing so can also allow the server to be overloaded and denied service. We test whether the instance is reachable from outside the network segment or reverse proxy it was intended to sit behind, and what an unauthenticated caller on that segment can actually read.
Admin API and Lifecycle Endpoints
Two flags control the most sensitive functionality on a Prometheus server: –web.enable-admin-api exposes administrative and mutating functionality, including deleting time series, under the /api/*/admin/ paths, and –web.enable-lifecycle exposes the /-/reload and /-/quit paths that reload the configuration or shut the process down over HTTP. Prometheus documents both flags as disabled by default, so either one being switched on is a deliberate operational choice rather than a default posture. We test whether either flag is enabled, whether the resulting endpoints are reachable by anyone besides the automation or operator they were enabled for, and what reloading or stopping the server would actually do to monitoring coverage.
TSDB Admin API and Time-Series Deletion
When –web.enable-admin-api is switched on, the TSDB admin API accepts POST or PUT requests to /api/v1/admin/tsdb/delete_series that mark matching series as deleted, alongside snapshot and clean-tombstones endpoints that operate on the on-disk storage directly. Prometheus’s own documentation notes that a delete only marks samples as deleted and that associated series metadata can still be returned in later metadata queries, so the operation is neither instant nor complete in the way a caller might expect. We test what the admin API can be made to delete or export, and whether the flag that exposes it is reachable from anywhere it should not be.
Remote Write and Remote Read Endpoints
A remote_write block sends every sample Prometheus scrapes onward to a remote endpoint over HTTP, and its authentication is whatever the operator configures: Prometheus’s configuration reference lists basic auth, a bearer token, OAuth2, AWS SigV4 (the scheme Amazon Managed Service for Prometheus expects) and Azure AD as mutually exclusive options, none of which is applied unless it is explicitly set. Prometheus’s security documentation separately warns that the remote read feature allows anyone with HTTP access to send queries to the remote read endpoint, and that if those queries are evaluated directly against a backing store such as a relational database, anyone able to query Prometheus this way can run arbitrary queries against that store. We test how each configured remote endpoint authenticates, and what a caller with only HTTP access to Prometheus can retrieve through it.
No User or Role Concept, Even Paired With Grafana
Prometheus has no concept of users, roles or organisations anywhere in its own product: its documented security model draws only one line, between trusted operators who can change the configuration file and command line, and everyone else, who is presumed to have HTTP access and can read every stored metric. This is a sharp contrast with Grafana, which is overwhelmingly deployed as the dashboard layer in front of Prometheus and which does apply organisations, roles and, in Enterprise or Cloud, data source permissions to what a viewer can query. Because Grafana’s data source proxy queries Prometheus with its own configured credentials rather than the viewer’s, Grafana’s role model narrows what a person sees in a dashboard, but it does nothing to narrow what Prometheus itself will answer for anyone who can reach it directly. We test the boundary between the two: what Prometheus will return to a direct, unauthenticated caller, regardless of how tightly Grafana’s own roles are configured in front of it.
HTTPS and Basic Authentication via web.yml
Prometheus can be configured with HTTPS and, separately, HTTP basic authentication, but Prometheus’s own documentation describes the whole feature as experimental and says it may change in future. Both are set in a YAML web configuration file loaded with the –web.config.file flag: a basic_auth_users block lists usernames against bcrypt-hashed passwords that get full access to the web server, and the documentation is explicit that if this block is left empty, no basic authentication is required at all. We test whether TLS and basic authentication have actually been configured on your instance, whether the credentials in use are unique to this deployment, and what is reachable if the web configuration file is left at its default, empty state.
Exporters and the Unauthenticated /metrics Endpoint
Prometheus’s security documentation names the /metrics endpoint of instrumented binaries specifically among the HTTP endpoints that should not be exposed to a public network, because exporters typically serve that endpoint without any authentication of their own. node_exporter is the most widely deployed example: its default collectors expose host-level detail read directly from the operating system, including CPU statistics, disk I/O, filesystem usage and DMI hardware information, to anyone who can reach the exporter’s own port, whether or not a Prometheus server is actually scraping it. We test which exporters are reachable, what each one’s /metrics endpoint actually discloses about the host or service behind it, and whether that exposure matches what the scraping Prometheus server was meant to see.
Federation and the /federate Endpoint
A Prometheus server can expose a /federate endpoint that returns the current value of whichever time series match the match[] parameters a requester supplies, and Prometheus’s federation documentation describes this as the mechanism for one server to scrape selected series from another. Because /federate is just another HTTP endpoint on the same server, it carries the same lack of built-in authentication as the rest of the API, and a federation relationship configured for one purpose can end up exposing more series than the receiving server was meant to see. We test which servers federate from this instance, what match[] patterns they are allowed to request, and whether federation quietly widens what a downstream server or caller can retrieve.
Service Discovery and Target Impersonation
Which targets Prometheus scrapes, how often, and with what labels is set entirely by the configuration file, and Prometheus’s documentation notes that where service discovery is used, some of that control effectively passes to anyone who can modify data in the service discovery system itself, such as a cloud provider’s tagging or a Kubernetes API. Prometheus also documents that a scraped target should not by default be able to expose data that impersonates a different target, but that the honor_labels option, and certain relabelling setups, remove that protection. We test what your service discovery configuration actually hands control to, and whether honor_labels or relabelling has been used in a way that lets one target present itself as another.
Managed Prometheus vs Self-Hosted
Several of the controls this page covers depend on how Prometheus is run: a self-managed instance leaves every flag, the web configuration file and every exporter’s exposure as the operator’s own responsibility, while a managed offering such as Amazon Managed Service for Prometheus or a Prometheus data source on Grafana Cloud moves some of that responsibility to the cloud vendor and authenticates ingestion through the vendor’s own mechanism, such as AWS SigV4 for Amazon Managed Service for Prometheus. Self-managed Prometheus is software you run yourself, so there is no vendor notification process to follow before testing your own instance; a managed Prometheus service is the cloud vendor’s own hosted platform, so we confirm that vendor’s current customer security-testing terms during scoping instead. We confirm which model applies to your deployment before scoping the engagement.
OUR PROCESS
Prometheus Security Review: From Scope to Attestation
Scope and Access
We agree which Prometheus instance, exporters, remote write endpoints and service discovery sources are in scope, plus network-level access to the HTTP endpoint and any web.yml credentials in use.
Configuration and Exposure Mapping
We map every admin and lifecycle flag, exporter, remote endpoint and service discovery source against what it actually exposes and to whom.
Manual Testing
A CREST-certified tester manually tests the HTTP endpoint, admin and lifecycle flags, remote write and read authentication, exporter exposure and service discovery boundaries, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Prometheus pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Prometheus Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 5 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote5 to 7 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Prometheus For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Prometheus Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Prometheus instance?
Network-level access to the instance’s HTTP endpoint from an agreed testing location is normally enough to start, plus a login or bearer token if basic authentication or a reverse proxy sits in front of it. If remote write, federation or an admin flag such as –web.enable-admin-api is in scope, we also agree access to those endpoints and any credentials they require.
Will testing touch our live metrics data?
Testing focuses on what the HTTP endpoint, admin API, exporters and any remote write or read endpoints expose and to whom, rather than analysing the metrics themselves for business meaning. Where proving a finding needs a test query or a temporary configuration change, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this for a self-hosted instance or a managed service like Amazon Managed Service for Prometheus?
Prometheus most commonly runs self-managed on your own infrastructure, and that is what this scope covers: the flags, web configuration file and exporters you control directly. A managed Prometheus service, such as Amazon Managed Service for Prometheus or a Prometheus data source on Grafana Cloud, is scoped separately because the cloud vendor’s own testing policy applies to it.
How long does a Prometheus security review take?
A single instance with a typical set of exporters, remote endpoints and service discovery sources sits within our 2-day single-instance scope, with a report landing around 5 working days after kickoff. An instance federating multiple servers, running many exporters, or using several remote write destinations extends that scope.
What is out of scope for a single-instance review?
Testing Prometheus’s own source code, the operating system it runs on beyond what an exporter discloses, or the backing store behind a remote write or read endpoint is not included, and we do not run denial-of-service testing against the server given how easily its own documentation says that can happen by accident. A connected exporter’s underlying application, or a downstream tool such as Grafana, is scoped and quoted separately.
Do you need admin access or our configuration file?
No. We test with the network access and any credentials you provide, and we do not need standing access to change the configuration file, rule files or command line beyond what is needed to verify a specific finding during the engagement.
Does Prometheus have a policy on customer penetration testing?
Self-managed Prometheus is software you run yourself, so there is no vendor notification process to follow before testing your own instance, and a genuine vulnerability in Prometheus’s own code is reported through the project’s published security process on GitHub instead. Where a managed Prometheus service such as Amazon Managed Service for Prometheus or Grafana Cloud is in scope, we confirm that cloud vendor’s current customer security-testing terms during scoping.
Are your testers CREST certified?
Yes. Every Prometheus engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Prometheus instance
Prometheus has no built-in authentication, so anyone reaching its HTTP endpoint can read every metric it stores. We test that endpoint, the admin API, remote write and every exporter feeding it. CREST-certified testers, fixed price from £2,670 for a 2-day single-instance scope, quoted within 24 hours.
