GeckoFlag is software that runs on your own server. So that you can entrust your project information to it with confidence, the developer personally runs security tests for every release and publishes what was tested and the results on this page.
This page is a record of self-assessment by the developer. It is not a certification or audit by a third party. Since we also publish what is tested, please use it as one input when deciding whether to adopt GeckoFlag.
- Built-in Safeguards
- Testing for Every Release
- Latest Test Results
- What We Don't Test
- Reporting Vulnerabilities
- Verifying Distributed Files
- Recommended Settings
Security Safeguards Built into the Design
GeckoFlag includes the following safeguards as standard. All of them are active without any configuration.
Password Protection
Passwords are never stored in plain text; they are hashed with bcrypt before being stored. Password reset tokens are also stored hashed, and the number of password reset requests is limited.
Login Attempt Limits
Failed logins are counted both per account and per client IP address, and login is temporarily restricted once a set number is exceeded. This mitigates brute-force attacks and attacks that target many accounts.
CSRF Protection
A token is verified on every form submission, preventing forged operations from external sites.
XSS Protection
Rich text in issues, comments, the Wiki, notes, and elsewhere is stored and displayed with only the tags allowed by HTML Purifier. Links are allowed only for http and https. Text generated by AI also goes through the same processing before it is stored.
SQL Injection Protection
Database operations use the CakePHP 5 ORM and prepared statements.
Host Header Validation
Links in password reset, invitation, and notification emails are built from the registered domain, not from the Host header of the request. A forged Host header cannot redirect the links in emails to an external address.
File Storage
Issue images and project files are stored outside the public folder and are served only after confirming that the viewer is a member of the project. Files with executable extensions such as PHP are not accepted.
API Key Encryption
The Claude API key for the AI features is encrypted before being stored in the database.
Claude Integration API Tokens
The Claude integration is off by default and can only be used when an administrator turns it on and allows it for each user. Only a hash of each API token is stored, and tokens can have an expiration date. Changing the password invalidates the tokens. The API checks the same permissions as the screens, and read-only tokens cannot change anything.
IP Address Restriction
Administrators can limit the IP addresses that are allowed access.
Installer Lockout
Once setup is complete, the installer screen can no longer be accessed.
Protection of Private Folders
On Apache, direct access to folders such as configuration, logs, and source code is denied by default (for Nginx, see Recommended Settings).
Automatic Backup Before Updates
A backup is created automatically before a software update.
Signature Verification of Update Files
Official update files carry the developer's digital signature (Ed25519). Before an update, the signature and the contents of every file are checked, and tampered files or unofficial update files are not applied.
Image Upload Validation
Images such as avatars, thumbnails, and logos have their format determined from the file contents and are saved under random file names. Nothing other than images is served from the image folders (on Apache). SVG is not accepted.
Security Headers
Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy are sent to prevent clickjacking and information leaking to external sites. When running over HTTPS, Strict-Transport-Security is also sent so that browsers always connect over HTTPS.
Session Management
A new session is created at every login. Permission changes, account deletion, and password changes take effect immediately, even on screens that are already logged in. Changing your email address or password requires entering your current password.
Security Testing for Every Release
Before a new version is released, the following tests are performed. Testing is done in a test environment with the same configuration as production, never against live services or customers' servers. The tests performed for the latest version are listed under "Latest Test Results".
| Category | What Is Tested | Tools / Standards | Frequency |
|---|---|---|---|
| Dependencies | Checks the libraries in use for known vulnerabilities and produces a list of the libraries used (SBOM) | composer audit, OSV-Scanner, CycloneDX | Every release |
| Static analysis | Detects, from the source code, paths by which input can reach dangerous operations (XSS, SQL injection, etc.) | Psalm (taint analysis), PHPStan (level 5), Semgrep | Every release |
| Leaked secrets | Whether passwords or API keys are included in the source code or distributed files | gitleaks | Every release |
| Dynamic scanning | Sends real attack requests while logged in as an administrator and as a regular user, and checks the responses | Nuclei | Every release |
| Permission testing | Whether issues, files, or notes in projects the user hasn't joined can be viewed or modified by changing the ID in the URL | Automated tests (PHPUnit), manual checks | Every release |
| File uploads | Whether executable files, files disguised as images, ZIP files that manipulate paths, and the like are rejected | Code review, manual checks | Every release |
| XSS | Enters attack strings into issue descriptions, comments, the Wiki, and AI-generated text, and checks that no script runs | Code review, manual checks | Every release |
| Checks by server configuration | For Apache and Nginx, and for each way of placing the public folder, whether configuration files or logs can be accessed directly | Manual checks | Every release |
| Claude integration extension | Known vulnerabilities in the libraries the extension uses, how the API token is handled, and restrictions on where requests are sent | npm audit, gitleaks, code review | Every extension release |
| Checklist self-assessment | Checks authentication, sessions, input validation, error handling, and more, item by item | Based on OWASP ASVS 5.0 Level 1; IPA (Japan): How to Secure Your Website | Every major version |
| Official website | HTTPS configuration and security headers of geckoflag.com | SSL Labs, Mozilla Observatory | Monthly |
If an issue of "High" or "Medium" severity is found, we don't release until it has been fixed and retested. "Low" issues are reviewed, and we either fix them or record why they have no impact.
Dependency Update Policy
Known vulnerabilities in the libraries GeckoFlag uses (such as CakePHP) are checked with every release. If a vulnerability affecting GeckoFlag is found, we aim to release a fixed version within the following time frames.
- "Critical" and "High" severity: within 14 days of disclosure
- "Medium" severity: within 30 days of disclosure
- "Low" severity: in the next release (within 90 days at the latest)
Even vulnerabilities that don't affect the way GeckoFlag uses a library are addressed by updating to a fixed version in the next release. Development-only libraries are not included in the distributed files.
Latest Test Results: v1.11.0
This round tested the changes since v1.10.0 (the Claude integration, text and background colors and dividers in rich text, and more), and also fixed issues that had been present in earlier versions. If you use v1.10.0 or earlier, we recommend updating to v1.11.0.
| Test | Tools (Version) | Findings (High / Medium / Low) | Action Taken |
|---|---|---|---|
| Dependencies | GitHub Advisory Database, FriendsOfPHP security-advisories (data as of 2026-10-28; 89 packages) | 0 / 0 / 0 | No known vulnerabilities in the libraries included in the distributed files. Known vulnerabilities in development-only libraries were resolved by updating them in v1.11.0 (development-only libraries are not included in the distributed files) |
| Static analysis / code review | Psalm 5.26.1 (taint analysis), PHPStan 2.1.17 (level 5), Semgrep 1.182.1, manual code review (changes since v1.10.0: the Claude integration API and tokens, rich text, staying signed in, software updates; plus the link output on every screen) | 1 / 1 / 3 | The High and Medium findings and 2 of the Low findings were fixed in v1.11.0. The remaining Low finding only occurs through the user's own actions, and its impact was confirmed to be limited. The High finding had been present in earlier versions |
| Leaked secrets | gitleaks 8.24.2 | 0 / 0 / 0 | Checked both the source code and the distributed files. Both of the 2 detections were false positives (such as sample strings in third-party libraries) |
| Fix verification | Functional checks in the test environment (PHP 8.3, MariaDB 10.11, Apache 2.4, Nginx 1.24, Chromium) | — | For each finding, confirmed that the original problem no longer reproduces |
| Dynamic scanning | Nuclei v3.11.1 (templates v10.5.1), run while logged out and as an administrator and a member | 0 / 0 / 0 | No issues |
| Permission testing | PHPUnit 12.5 (454 automated tests; in addition to the previous checks, confirmed that the Claude integration API refuses requests without a token, with a read-only token, from users who are not allowed, and when the feature is turned off, and never reaches projects the user hasn't joined) | 0 / 0 / 0 | No issues |
| Checks by server configuration | Manual (two ways of placing the public folder on Apache 2.4 and Nginx 1.24; 39 URLs including configuration files, logs, sessions, and stored files) | 0 / 0 / 1 | Fixed in v1.11.0: direct access to the file folder used by older versions (files) is now refused entirely on Apache as well. No other issues |
| Checklist | OWASP ASVS 5.0 Level 1 (70 items) | 50 of 56 applicable items met | Not reviewed this time (the result of v1.10.0 is carried over) |
| Claude integration extension | npm audit, gitleaks 8.24.2, mcpb validate, manual code review (geckoflag-1.0.0.mcpb) | 0 / 0 / 0 | No known vulnerabilities affecting the libraries included in the distributed file. Checked how the API token is handled and the restrictions on where requests are sent (HTTPS only, redirects not followed) |
Test results for every version, including earlier ones, are kept on the “Past Test Results” page.
What We Don't Test
The testing described above has the following limitations. Please take them into account when considering GeckoFlag.
- No third-party testing has been performed. At this time, no source code review or penetration testing by external experts has been carried out.
- Your server environment is outside the scope of testing. Security depends heavily on the configuration and update status of the OS, web server, PHP, and database.
- Not every hosting environment has been checked. The configurations tested are limited to those listed under "Latest Test Results".
- External services are out of scope. The security of Anthropic's API used by the AI features, the Claude desktop app used by the Claude integration, mail servers, and other external services depends on their respective providers.
- Issues automated tools don't detect. Types of issues that tools don't detect (such as flaws in business logic) are covered by manual testing, but not everything can be covered.
Reporting a Vulnerability
If you find what appears to be a vulnerability in GeckoFlag, please contact us directly through the channel below rather than in a public place. The developer personally reads every report.
How to report: Use the contact form and select "Vulnerability Report" as the inquiry type
What to Include in Your Report
- The affected version and the screen or feature where the problem occurs
- Steps to reproduce (as far as possible)
- The expected impact
- Your server environment (PHP, web server, etc.)
Our Request
- Please test only in an environment you manage yourself, and do not perform any offensive actions against GeckoFlag installations operated by others or against geckoflag.com.
If you wish, we will credit you by name in the security notice for the fixed version.
SHA-256 of Distributed Files
You can check whether a downloaded file is identical to the official one by comparing it with the values below.
| File | SHA-256 |
|---|---|
| GeckoFlag - 1.11.0.zip | 33354ac588c4cb4de2953c3c26a484953c2bb886f38196ba4bcf4fe629648399 |
| geckoflag-1.0.0.mcpb | 44f2c6dfc9f437856d0680920a327820d757a14116064faa6e46ad8a961d0747 |
How to check: on Windows, run Get-FileHash filename -Algorithm SHA256 in PowerShell; on macOS or Linux, run shasum -a 256 filename.
Recommended Settings for Safe Use
The security of GeckoFlag also depends on the configuration of the server it is installed on. We recommend the following settings.
- Complete the installation right after uploading: Until the installation is finished, anyone who knows the URL can open the setup screen. Complete the installation as soon as you have placed the files.
- Run over HTTPS: Login credentials and project content are encrypted in transit. Many hosting providers offer free SSL certificates. Note that once the site has been opened over HTTPS, browsers will connect to that address over HTTPS for the following year (v1.10.0+). Please keep this in mind if you plan to stop using HTTPS.
- Set the public folder (document root) to webroot: This places configuration files and logs where they can't be reached from the web.
- If you use Nginx, add the configuration: .htaccess has no effect on Nginx. Separately configure it to deny access to private folders and not to execute PHP in the image upload folder (webroot/img). For a configuration example, see the manual (Installation).
- Update to the latest version: Security fixes are delivered in the latest version. Obtain update files from the official website and verify their SHA-256. From v1.10.0 onward, the signature is also verified automatically before an update.
- Keep PHP and your database on supported versions: PHP versions that have reached end of support no longer receive fixes.
- Protect administrator accounts: Use long passwords that are hard to guess, and grant administrator permissions only to those who need them.
- Use IP restriction for internal use: Under Settings, you can limit the IP addresses allowed access.
- Back up regularly: Store your database and uploaded files in a location separate from the server.