Security

Last updated: May 29, 2026

This page describes Kanto’s current security posture at a high level. It is meant to explain the kinds of controls Kanto uses today, the limits of those controls, and what users should expect from a small independently operated service.

1. Security Philosophy

Kanto aims for practical, best-effort security rather than marketing language about “perfect protection.” The goal is to reduce common abuse, protect account access, and operate responsibly with the resources currently available. That means Kanto takes security seriously, but does not claim absolute safety or invulnerability.

2. Authentication and Account Access

• Kanto uses better-auth with a server-side Drizzle/Postgres adapter for account and session management.
• Password-based authentication is used for account access.
• Email verification is used to unlock fuller account privileges.
• Session handling is used to keep users signed in and manage account access over time.
• Password changes require the current password, and account deletion or other sensitive actions require an authenticated session.

3. Verification and Trust Controls

Kanto uses verification state to distinguish between unverified and verified accounts. Unverified accounts have reduced privileges because feature gating is one of the simplest ways to reduce spam, throwaway abuse, and low-effort account churn.

4. Rate Limiting and Abuse Reduction

Kanto uses rate limiting and related operational controls to reduce abuse, especially around actions like posting, replying, or voting. These controls are not described in exhaustive implementation detail on this page because publishing every internal threshold would make abuse easier, but the existence of rate limiting is part of the security model.

Kanto also keeps request-throttle and rate-limit event records for certain actions. In some cases actor identifiers are reduced to derived keys before they are stored so the app can throttle behavior without exposing raw internal matching rules in product copy.

5. Moderation as a Security Layer

Moderation is not only a content layer; it is also part of Kanto’s security model. Site moderators and community moderators can intervene when users, boards, or content create product, safety, or abuse risk. Actions may include muting, banning, locking, freezing, hiding, quarantining, content removal, or related enforcement steps.

6. Hosting and Infrastructure

Kanto is currently deployed using modern hosted infrastructure. The application layer runs on Vercel. The database runs on Supabase Postgres, hosted in the EU region. Both providers operate their own infrastructure security controls, including encryption at rest, encrypted connections, access controls, and operational monitoring. Those providers form part of the real-world security boundary of the service. Kanto connects to the database server-side only through the application layer; no database credentials are exposed to the browser or end users.

The current database client uses TLS-enabled Postgres connections from the server runtime. Browser clients do not receive direct database access, direct SQL credentials, or privileged service-role access.

7. Email Security

Kanto uses an external email delivery provider for verification and serious operational email. The current app supports Resend or Brevo depending on configuration. Verification links are delivered only through the configured email provider and are not stored in ordinary in-product notifications or logs. Email delivery providers are necessary for sending account-related messages, but email itself should never be treated as a perfectly secure medium.

8. Direct Message Confidentiality

Kanto direct messages are not marketed here as end-to-end encrypted because they are not. Current direct messages are encrypted at rest inside the application data store and notification previews do not include message content, but the server still processes plaintext during normal delivery and retrieval. That is materially better than raw plaintext storage, but it is not cryptographic sender-to-recipient secrecy from the service operator.

9. Input Validation and Request Hardening

Kanto validates and normalizes a range of incoming application data server-side. Current request handling includes JSON object enforcement on selected endpoints, body-size limits, control-character stripping, plain-text normalization, URL and avatar URL validation, boolean normalization, integer bounds checks, enum allow-lists, and hex color validation where relevant. These controls are meant to reduce malformed input, accidental over-collection, and easy abuse paths.

10. Anonymous Posting Security Model

Kanto supports anonymous posting in communities that enable it. From a security perspective, anonymous posting is a display-layer feature, not a network-layer or cryptographic anonymity system. The following applies:

• Anonymous posts are linked to the poster's account server-side for rate-limiting, abuse prevention, and moderation.
• The anonymous code shown in a thread (e.g. "Anon#4f2c") is a per-session, per-thread identifier derived from the post — it does not identify your account to other users.
• Moderation actions can still be applied to accounts that post anonymously, as the account association is retained internally.
• If a one-time deletion token is issued for an anonymous post, the token is hashed before storage. The plain token is shown once and not stored in recoverable form.
• Anonymous posts do not appear on a user's public profile and do not show a username in the thread view.

Users who need stronger anonymity guarantees should not rely on Kanto's anonymous posting feature and should use appropriate tools and services outside this platform.

11. Data Minimization and Deletion

Kanto aims to process the data needed to provide the app’s existing features rather than collect broad unrelated user profiles. For deleted accounts, Kanto’s intended model is permanent deletion in the overwhelming majority of cases rather than indefinite retention of extensive user archives or moderation histories.

The current delete flow is intended to remove more than a profile row. It also attempts to remove linked sessions, auth account rows, verification rows, follows, votes, community profiles, notifications, owned communities, authored threads, authored replies, and many directly associated moderation/report rows.

Kanto also runs scheduled retention enforcement for selected short-lived operational records. Expired sessions and verification artifacts are purged, and short-retention abuse telemetry is deleted on defined windows instead of being kept indefinitely by accident.

12. Incident Handling

If Kanto becomes aware of a serious security issue, the operator may investigate, contain, patch, rotate credentials, restrict affected features, or notify affected users when appropriate. Not every operational issue will result in a public incident report, but material security issues may lead to direct user communication or visible service changes.

13. Moderation, Auditability, and Safety Workflows

Kanto’s security model includes persistent moderation records and request workflows. Reports, moderation actions, moderation requests, moderation-request messages, and notification links create an auditable trail for account restrictions, appeals, privacy requests, and correction requests. This is partly a safety feature and partly a control against silent or unreviewable account actions.

14. Limits of Security Guarantees

No online service can honestly guarantee perfect confidentiality, integrity, or availability. This includes Kanto. Risks may arise from software bugs, supply chain problems, infrastructure outages, credential theft, user-side device compromise, social engineering, legal compulsion, or ordinary human error.

15. What Users Should Do

• Use a strong, unique password.
• Verify your email and keep access to that inbox secure.
• Do not reuse Kanto credentials on other services.
• Report suspicious activity, impersonation, or abuse quickly.
• Remember that content posted publicly may be copied by others even if later deleted.

16. Reporting Security Issues

If you believe you found a security issue in Kanto, contact axeeeeeel@proton.me. Please include enough detail to reproduce the issue and avoid public disclosure before there has been a reasonable chance to investigate.

17. Current Security Position Summary

Kanto currently relies on a combination of:

• Password-based authentication and session management via a server-side auth layer.
• Email verification.
• Application-layer encryption at rest for direct-message bodies.
• Hashed one-time or bearer-style app-owned tokens where supported by the app’s own flows.
• Server-side-only database access to Supabase Postgres.
• Content-Security-Policy and transport/security headers at the middleware layer.
• Input normalization, body-size limits, and request validation on selected endpoints.
• Rate limiting and abuse controls.
• Scheduled retention enforcement for short-lived operational records.
• Manual moderation and enforcement tools.
• Hosted infrastructure security controls via Vercel, Supabase, and the configured email provider.
• Best-effort operational judgment by the service operator.

This page is descriptive, not a warranty. It does not create a contractual promise that every control will always exist or perform perfectly under all conditions.