Home Explore Help
Sign In
mirrors
/
wekan
mirror of https://github.com/wekan/wekan.git
2
0
Fork 0
Files Issues 0 Wiki
Tree: v8.16
Branches Tags
wekan
/
SECURITY.md

SECURITY.md 15 KB
Permalink History Raw

About money, see CONTRIBUTING.md

Security is very important to us. If you discover any issue regarding security, please disclose the information responsibly by sending an email from Protonmail to security@wekan.fi that is Protomail email address, or by using this PGP key security-at-wekan.fi.asc to security@wekan.fi and not by creating a GitHub issue. We will respond swiftly to fix verifiable security issues.

We thank you with a place at our hall of fame page, that is at https://wekan.fi/hall-of-fame

How should reports be formatted?

Name: %name
Twitter: %twitter
Bug type: %bugtype
Domain: %domain
Severity: %severity
URL: %url
PoC: %poc
CVSS (optional): %cvss
CWSS (optional): %cwss

Who can participate in the program

Anyone who reports a unique security issue in scope and does not disclose it to a third party before we have patched and updated may be upon their approval added to the Wekan Hall of Fame.

Which domains are in scope?

No public domains, because all those are donated to Wekan Open Source project, and we don't have any permissions to do security scans on those donated servers.

Please don't perform research that could impact other users. Secondly, please keep the reports short and succinct. If we fail to understand the logics of your bug, we will tell you.

You can Install Wekan to your own computer and scan it's vulnerabilities there.

About Wekan versions

There are only 2 versions of Wekan: Standalone Wekan, and Sandstorm Wekan.

Standalone Wekan Security

Standalone Wekan includes all non-Sandstorm platforms. Some Standalone Wekan platforms like Snap and Docker have their own specific sandboxing etc features.

Standalone Wekan by default does not load any files from Internet, like fonts, CSS, etc. This also means all Standalone Wekan functionality works in offline local networks. WeKan is used at most countries of the world https://snapcraft.io/wekan and by by companies that have 30k users.

  • Wekan private board attachments are not accessible without logging in.
  • There is feature to set board public, so that board is visible without logging in in readonly mode, with realtime updates.
  • Admin Panel has feature to disable all public boards, so all boards are private.

SSL/TLS

XSS

QA about PubSub

Q:

Hello, I have just seen the Meteor DevTools Evolved extension and was wondering if anyone had asked themselves the question of security. Insofar as all data is shown in the minimongo tab in plain text. How can data be hidden from this extension?

A:

PubSub

PubSub: Fix that user can not change to Admin

Permissions and Roles

Environment variables

  • For any passwords, use environment variables, those are serverside

  • Do not copy environment variable to public variable that is visible browserside https://github.com/wekan/wekan/blob/main/server/max-size.js

    Meteor.startup(() => {
if (process.env.HEADER_LOGIN_ID) {
Meteor.settings.public.attachmentsUploadMaxSize   = process.env.ATTACHMENTS_UPLOAD_MAX_SIZE;
Meteor.settings.public.attachmentsUploadMimeTypes = process.env.ATTACHMENTS_UPLOAD_MIME_TYPES;
Meteor.settings.public.avatarsUploadMaxSize       = process.env.AVATARS_UPLOAD_MAX_SIZE;

  • For serverside, you can set Meteor.settings.variablename, without text public

  • For WeKan kanban, there is feature for setting board public, it can be viewed by anyone, there is realtime updates. But

  • Some of those permissions are checked at users.js models at https://github.com/wekan/wekan/tree/main/models

  • Environment variables are used for email server passwords, etc, at all platforms https://github.com/wekan/wekan/commit/a781c0e7dcfdbe34c1483ee83cec12455b7026f7

Escape HTML comment tags so that HTML comments are visible

Attachments: XSS in filename is sanitized

Attachments: Forced download to prevent stored XSS

  • To prevent browser-side execution of uploaded content under the app origin, all attachment downloads are served with safe headers:
    • Content-Type: application/octet-stream
    • Content-Disposition: attachment
    • X-Content-Type-Options: nosniff
    • A restrictive Content-Security-Policy with sandbox
  • This means attachments are downloaded instead of rendered inline by default. This mitigates HTML/JS/SVG based stored XSS vectors.
  • Avatars and inline images remain supported but SVG uploads are blocked and never rendered inline.

Users: Client update restrictions

  • Client-side updates to user documents are limited to safe fields only:
    • username
    • profile.*
  • Sensitive fields are blocked from any client updates and can only be modified by server methods with authorization:
    • orgs, teams, roles, isAdmin, createdThroughApi, loginDisabled, authenticationMethod, services.*, emails.*, sessionData.*
  • Attempts to update forbidden fields from the client are denied.
  • Admin operations like managing org/team membership or toggling flags must use server methods that check permissions.

Voting: integrity and authorization

  • Client updates to card vote fields are blocked to prevent forged votes and inconsistent policy enforcement.
  • Voting is performed via a server method that enforces:
    • Authentication and board membership, or an explicit per-card flag allowing non-members to vote.
    • Only the caller's own userId is added/removed from vote.positive/vote.negative.
  • This prevents members from fabricating other users' votes and ensures non-members cannot vote unless explicitly allowed.

Planning Poker: integrity and authorization

  • Client updates to card poker fields are blocked. All poker actions go through server methods that enforce:
    • Authentication and board membership for configuration and results.
    • For casting a poker vote, either board membership or an explicit per-card flag allowing non-members to participate.
    • Only the caller's own userId is added/removed from the selected estimation bucket (e.g., one, two, five, etc.).
  • Methods cover setting/unsetting poker question/end, casting votes, replaying, and setting final estimation.

Attachment API: authentication and DoS prevention

  • The attachment API (/api/attachment/*) requires proper authentication using X-User-Id and X-Auth-Token headers.
  • Authentication validates tokens by hashing with Accounts._hashLoginToken and matching against stored login tokens, preventing identity spoofing.
  • Request handlers implement:
    • 30-second timeout to prevent hanging connections.
    • Request body size limits (50MB for uploads, 10MB for metadata operations).
    • Proper error handling and guaranteed response completion.
    • Request error event handlers to clean up failed connections.
  • This prevents:
    • DoS attacks via concurrent unauthenticated or malformed requests.
    • Identity spoofing by using arbitrary bearer tokens or user IDs.
    • Resource exhaustion from hanging connections or excessive payloads.
  • Access control: all attachment operations verify board membership before allowing access.

Brute force login protection

Sandstorm Wekan Security

On Sandstorm platform using environment variable Standalone Wekan features like Admin Panel etc are turned off, because Sandstorm platform provides SSO for all apps running on Sandstorm.

Sandstorm is separate Open Source platform that has been security audited and found bugs fixed. Sandstorm also has passwordless login, LDAP, SAML, Google etc auth options already. At Sandstorm code is read-only and signed by app maintainers, only grain content can be modified. Wekan at Sandstorm runs in sandboxed grain, it does not have access elsewhere without user-visible PowerBox request or opening randomly-generated API key URL. Also read Sandstorm Security Practices and Sandstorm Security non-events. For Sandstorm specific security issues you can contact kentonv by email.

What Wekan bugs are eligible?

Any typical web security bugs. If any of the previously mentioned is somehow problematic and a security issue, we'd like to know about it, and also how to fix it:

  • Cross-site Scripting
  • Open redirect
  • Cross-site request forgery
  • File inclusion
  • Authentication bypass
  • Server-side code execution

What Wekan bugs are NOT eligible?

Typical already known or "no impact" bugs such as:

  • Wekan API old tokens not replaced correctly
  • Missing Cookie flags on non-session cookies or 3rd party cookies
  • Logout CSRF
  • Social engineering
  • Denial of service
  • SSL BEAST/CRIME/etc. Wekan does not have SSL built-in, it uses Caddy/Nginx/Apache etc at front. Integrated Caddy support is updated often.
  • Email spoofing, SPF, DMARC & DKIM. Wekan does not include email server.

Wekan is Open Source with MIT license, and free to use also for commercial use. We welcome all fixes to improve security by email to security@wekan.team

Bonus Points

If your Responsible Security Disclosure includes code for fixing security issue, you get bonus points, as seen on Hall of Fame.