Ki-Ki

Contents

1. Who this policy is for and what it covers

This policy is for anyone who:

• Has found, or thinks they may have found, a security issue related to Ki-Ki
• Wants to understand what is in scope for testing
• Needs to know how Ki-Ki handles security telemetry and logs

It covers systems under the direct control of Ki-Ki, which is currently operated by Kieron JH in the North East of England.

This policy does not give you permission to attack systems that belong to someone else, even if Ki-Ki has helped them with their web stack.

2. Summary of the security reporting approach

Ki-Ki welcomes good faith reports of genuine security issues. The goal is simple:

• Make it easy to report concerns to the right place
• Respond in a sensible timeframe based on risk
• Fix real problems as quickly as reasonably possible
• Respect researchers who act within the law and within this policy

Ki-Ki does not offer a cash bug bounty at this time. Effort that helps tighten the system is still valued and appreciated.

3. Scope and out of scope targets

3.1 In scope

The following are in scope for security reports and cautious testing:

• The main site at ki-ki.co.uk
• Any subdomains that clearly belong to Ki-Ki, such as *.ki-ki.co.uk
• Cloudflare Workers and related logic that serve Ki-Ki content

3.2 Out of scope

The following are out of scope and must not be targeted:

• Websites, email systems, or infrastructure owned by Ki-Ki clients or partners
• Cloudflare, Porkbun, email providers, or other suppliers as independent controllers
• Any environment where you do not have permission from the owner to test

If you believe you have found an issue on a client system that mentions Ki-Ki by name, you can still contact Ki-Ki, but the primary relationship is between you and that organisation. Do not use Ki-Ki as a route to justify tests that breach their terms, contracts, or the law.

4. How to report a security issue

To report a vulnerability or suspicious behaviour, use one of the following contact routes:

• Email: [email protected]
• Alternative: [email protected]
• PGP: see the Secure contact and PGP key page for encryption details

For serious issues that could expose data or disrupt service, include [URGENT] in the email subject.

Helpful details to include:

• A clear description of the issue
• The full URL or endpoint you tested
• Step by step instructions to reproduce the problem
• What you expected to happen and what actually happened
• Any relevant request or response snippets, headers, or screenshots
• Your view of likely impact, for example data exposure or privilege escalation

Please avoid sending live credentials, long dumps of production data, or material that identifies third parties unless it is strictly necessary to understand the issue.

5. What you can expect in return

When you report a security issue in line with this policy and within the law, you can expect:

• An acknowledgement within a reasonable timeframe, typically within three working days
• A basic initial assessment of severity and whether the issue can be reproduced
• Prioritisation based on risk and practical impact, not noise
• Updates once the issue is confirmed, mitigated, or resolved, where ongoing dialogue is needed
• No legal threats or hostile treatment purely for raising a concern in good faith

There is no formal hall of fame at this time. If you would like credit and it is safe and appropriate, that can be discussed privately.

6. Safe and unacceptable testing

Ki-Ki relies on strict logging, Cloudflare protection, and custom fingerprinting. Testing that looks obviously abusive or destructive will be blocked and may be escalated. The aim is to keep room for careful research, not to host a stress test range.

6.1 Examples of acceptable behaviour

• Inspecting HTTP response headers, TLS configuration, and visible security settings
• Low volume checks for common misconfigurations that do not compromise real data
• Reporting exposed debug information, unintended directory listing, or similar issues
• Checking error handling and input validation with a small number of requests

6.2 Behaviour that is not allowed

• Denial of service activity or load tests designed to exhaust resources
• Brute force attempts against passwords, tokens, or login endpoints
• Deliberate attempts to evade or disable logging, fingerprinting, or monitoring
• Accessing, modifying, or deleting data that you are not entitled to see
• Social engineering, phishing, or attacks against individuals or client staff
• Automated scanning at a volume that looks like a generic vulnerability sweep

If you accidentally encounter data that belongs to someone else, stop, avoid saving or sharing it, and only include the minimum detail needed in your report.

7. Logging, monitoring, and evidence

Ki-Ki takes logging seriously. Typical data recorded for security and operational purposes can include:

• IP addresses, network ranges, and autonomous system numbers (ASN)
• Request paths, methods, and headers
• User agent strings and basic device characteristics
• Cloudflare events, Worker level telemetry, and rule matches
• Security alerts forwarded to a private Discord channel for review

Logs are used to:

• Spot and block abusive or automated activity
• Investigate incidents and suspicious behaviour
• Refine protective rules over time
• Provide evidence if a serious incident requires regulatory or legal follow up

Logging is focused on security and reliability. Ki-Ki does not use this data to build commercial tracking profiles or to sell to third parties.

8. Legal position

Ki-Ki operates from the UK and is subject to the Computer Misuse Act and related laws. You are responsible for making sure that any testing you perform is lawful in your own jurisdiction and in the UK.

If activity clearly appears malicious, causes disruption, or involves attempts to bypass controls in a way that cannot be justified as cautious research, Ki-Ki may:

• Block or rate limit traffic at the edge
• Preserve and review relevant logs and telemetry
• Share information with hosting providers, Cloudflare, or law enforcement where appropriate

Reports that stay within this policy and within the law will be treated as good faith research, even if the underlying issue turns out to be low risk or already known.

9. Changes to this policy

Ki-Ki’s security stack and service offering will change over time. When those changes affect how security reports are handled or how testing should be approached, this page will be updated.

The “last updated” date at the top of this page shows when the policy was most recently revised. Updates may also be reflected in the security.txt file at the root of the site.