- Description: An attacker crafts and sends HTTP requests directly to the
matomo.php
tracking endpoint, simulating legitimate user activity. They might use automated scripts to generate large volumes of fake page views, events, or conversions. They could also inject invalid or malicious data into custom dimensions or variables. - Impact: Skewed analytics data, leading to incorrect business decisions. Potential for denial-of-service if the volume of fake data is high enough. Data integrity is compromised. False positives in fraud detection systems relying on Matomo data.
- Affected Component:
matomo.php
(Tracking API endpoint),Tracker
class (and related methods for processing tracking requests). - Risk Severity: High
- Mitigation Strategies:
- Mandatory
token_auth
: Require thetoken_auth
parameter for all tracking requests. Treat this token as a secret and rotate it regularly. - Input Validation: Strictly validate all input parameters in tracking requests, including
_id
(visitor ID),url
,action_name
, custom dimensions, etc. Reject requests with invalid or unexpected data. - Rate Limiting: Implement rate limiting on the
matomo.php
endpoint to prevent rapid injection of fake data. Consider different rate limits based on IP address, user agent, or other factors. - Referrer Validation: If appropriate for the application, validate the
Referer
header (though it can be spoofed, it adds a layer of difficulty). - Server-Side Validation: Whenever possible, validate user actions on the server-side before sending tracking data to Matomo. For example, don't track a "purchase" event until the purchase is confirmed in the backend.
- Anomaly Detection: Monitor Matomo data for unusual spikes in traffic, unexpected patterns, or suspicious user behavior. Set up alerts for these anomalies.
- Content Security Policy (CSP): Use a CSP to restrict the domains from which tracking requests can originate.
- Mandatory
- Description: An attacker gains unauthorized access to the Matomo server and modifies the
config/config.ini.php
file. They could change tracking settings, disable security features (liketoken_auth
), alter database credentials, or inject malicious JavaScript into the tracking code. This threat assumes the attacker has already bypassed server-level security. - Impact: Complete compromise of the Matomo installation. Data loss, data corruption, data exfiltration, potential for cross-site scripting (XSS) attacks against users of the tracked websites. Loss of control over the analytics data.
- Affected Component:
config/config.ini.php
(Main configuration file). - Risk Severity: Critical
- Mitigation Strategies:
- Strict File Permissions: Set the most restrictive file permissions possible on
config/config.ini.php
. It should be readable only by the web server user and writable only by a designated administrator account (and ideally, only during configuration changes). - File Integrity Monitoring (FIM): Use a FIM tool to monitor the integrity of
config/config.ini.php
and alert on any unauthorized changes. - Version Control: Store the configuration file in a version control system (e.g., Git) to track changes and facilitate rollbacks.
- Strict File Permissions: Set the most restrictive file permissions possible on
- Description: An attacker gains direct access to the Matomo database. They could alter or delete tracking data, inject malicious data, or extract sensitive information. This threat assumes the attacker has already bypassed server and application-level security to reach the database directly.
- Impact: Data loss, data corruption, data exfiltration. Compromised data integrity. Potential for denial-of-service if the database is corrupted or overloaded.
- Affected Component: Matomo database (all tables).
- Risk Severity: Critical
- Mitigation Strategies:
- Strong Database Credentials: Use a strong, unique password for the Matomo database user. Avoid using the default credentials.
- Database Access Control: Restrict database access to only the necessary hosts (typically the web server). Use a firewall to block external access to the database port.
- Principle of Least Privilege (Database User): Grant the Matomo database user only the minimum necessary privileges (SELECT, INSERT, UPDATE, DELETE on the Matomo tables). Do not grant administrative privileges.
- Database Monitoring and Auditing: Implement database monitoring and auditing to detect unauthorized access or modifications.
- Regular Backups: Regularly back up the Matomo database to a secure location. Test the restoration process regularly.
- Description: An attacker installs a malicious plugin through the Matomo Marketplace or by directly uploading it to the server. Alternatively, they might modify an existing plugin to inject malicious code. The malicious plugin could steal data, modify tracking behavior, or provide a backdoor to the server.
- Impact: Data exfiltration, data corruption, potential for cross-site scripting (XSS) attacks, denial-of-service, complete server compromise.
- Affected Component:
plugins/
directory, individual plugin files, Plugin API. - Risk Severity: High
- Mitigation Strategies:
- Trusted Sources: Only install plugins from the official Matomo Marketplace or other trusted sources. Verify the reputation and reviews of the plugin developer.
- Plugin Updates: Keep all plugins up to date. Enable automatic updates if available and reliable.
- Plugin Review: Regularly review installed plugins and remove any that are unnecessary or suspicious.
- File Integrity Monitoring (FIM): Monitor the
plugins/
directory for unauthorized changes. - Code Review (if possible): If you have the expertise, review the source code of plugins before installing them, especially if they are from less-known sources.
- Description: An attacker gains access to the raw tracking data stored in the Matomo database, either through direct database access or by exploiting a vulnerability in Matomo or another application. This data could include IP addresses, user IDs, browsing history, custom dimensions, and other potentially sensitive information.
- Impact: Privacy violation, potential for identity theft, reputational damage, legal consequences (depending on data privacy regulations).
- Affected Component: Matomo database (especially tables like
log_visit
,log_link_visit_action
,log_conversion
). - Risk Severity: High
- Mitigation Strategies:
- Database Security: Implement all database security measures described in the "Matomo Database Modification" threat.
- Data Anonymization: Use Matomo's built-in data anonymization features, such as IP address masking, user ID pseudonymization, and data retention policies.
- Data Minimization: Only collect the data that is absolutely necessary for your analytics needs. Avoid collecting sensitive personal information if possible.
- Encryption at Rest: Encrypt the database at rest using database-level encryption or full-disk encryption.
- Encryption in Transit: Ensure that all communication between the web server and the database server is encrypted (e.g., using TLS/SSL).
- Access Control: Restrict access to the Matomo database to only authorized personnel.
- Description: An attacker gains access to a Matomo administrative account, either through password guessing, phishing, session hijacking, or exploiting a vulnerability in Matomo. With administrative access, they can control all aspects of the Matomo installation.
- Impact: Complete compromise of the Matomo installation. Data loss, data corruption, data exfiltration, potential for cross-site scripting (XSS) attacks, denial-of-service.
- Affected Component: Matomo user authentication system, administrative interface.
- Risk Severity: Critical
- Mitigation Strategies:
- Strong Passwords: Enforce strong, unique passwords for all Matomo user accounts, especially administrative accounts.
- Two-Factor Authentication (2FA): Enable 2FA for all Matomo user accounts, especially administrative accounts. Matomo supports various 2FA methods.
- Session Management: Use secure session management practices, including short session timeouts, secure cookies (HTTPS only, HttpOnly flag), and protection against session fixation.
- Regular Security Audits: Regularly review user accounts and permissions to ensure they are still appropriate. Remove any unnecessary accounts.
- Principle of Least Privilege: Grant users only the minimum necessary permissions to perform their tasks. Avoid granting administrative privileges to users who don't need them.
- Keep Matomo Updated: Regularly update Matomo to the latest version to patch security vulnerabilities.
- Description: An attacker exploits a known or zero-day vulnerability in the Matomo core code (e.g., a cross-site scripting (XSS) vulnerability, a SQL injection vulnerability, a remote code execution (RCE) vulnerability).
- Impact: Varies depending on the vulnerability, but could range from data exfiltration and data corruption to complete server compromise and denial-of-service.
- Affected Component: Varies depending on the vulnerability; could be any part of the Matomo core code.
- Risk Severity: Critical (for RCE or high-impact vulnerabilities), High (for other significant vulnerabilities).
- Mitigation Strategies:
- Keep Matomo Updated: This is the most important mitigation. Regularly update Matomo to the latest version to patch security vulnerabilities. Subscribe to Matomo's security advisories.
- Web Application Firewall (WAF): A WAF can help to mitigate some vulnerabilities, especially XSS and SQL injection.
- Security Hardening: Follow Matomo's security hardening guidelines.
- Vulnerability Scanning: Regularly scan your Matomo installation for vulnerabilities using a vulnerability scanner.
- Penetration Testing: Consider periodic penetration testing to identify and address vulnerabilities.
- Description: An attacker tricks an authenticated Matomo user into performing an unintended action, such as changing settings or deleting data, by crafting a malicious link or form.
- Impact: Unauthorized modification of Matomo configuration or data.
- Affected Component: Any Matomo UI component that handles user input and performs actions without proper CSRF protection.
- Risk Severity: High
- Mitigation Strategies:
- CSRF Tokens: Ensure that all Matomo forms and API endpoints that perform state-changing actions use CSRF tokens to prevent cross-site request forgery. Matomo should have this built-in, but verify its proper implementation.
- Keep Matomo Updated: Ensure you are running a version of Matomo with up-to-date CSRF protections.