Security & Vulnerability Disclosure

Last updated: July 14, 2026

Schedesk takes the security of our customers' workplace data seriously. This page describes how to report a security vulnerability to us, what you can expect in return, and the safeguards we have in place. We welcome reports from security researchers and treat them as a gift, not a threat.

Reporting a Vulnerability

If you believe you have found a security vulnerability in Schedesk, please report it privately by email to security@schedesk.com.

To help us reproduce and fix the issue quickly, please include:

  • A clear description of the vulnerability and the affected component (web app, API, Slack app, or mobile app)
  • Step-by-step instructions to reproduce the issue
  • The impact you believe an attacker could achieve
  • Supporting evidence such as a proof-of-concept request, screenshot, or short video
  • How you would like to be credited, if you would like to be credited at all

Please report the issue to us privately and give us a reasonable opportunity to fix it before disclosing it publicly or to any third party. Do not access, modify, or delete data belonging to other users, and use only test accounts you control.

Scope

This vulnerability disclosure program covers all Schedesk-operated services, including:

  • The Schedesk web application and marketing site (schedesk.com and its subdomains)
  • The Schedesk API, including authentication, authorization, and OAuth flows
  • The Schedesk Slack app, including its OAuth installation flow, slash commands, event handling, and the handling of Slack tokens and workspace data
  • The Schedesk mobile applications for iOS and Android

Out of Scope

The following are generally not eligible under this program:

  • Denial-of-service, volumetric, or resource-exhaustion attacks against our infrastructure
  • Social engineering, phishing, or physical attacks against Schedesk staff, users, or offices
  • Spam, or issues that require the victim to have already been compromised
  • Vulnerabilities in third-party services we depend on (report those to the vendor directly; tell us if we are affected)
  • Raw output from automated scanners without a demonstrated, exploitable impact
  • Missing best-practice headers or configuration with no demonstrated security impact

Safe Harbor

We will not pursue or support legal action against security researchers who discover and report vulnerabilities in good faith and in accordance with this policy. We consider such research to be authorized conduct, and we will work with you to understand and resolve the issue quickly.

This safe harbor applies as long as you make a good-faith effort to avoid privacy violations, data destruction, service degradation, and disruption to other users; you do not exfiltrate, retain, or publish customer data; and you give us reasonable time to remediate before any public disclosure.

Our Commitments

When you report a vulnerability to us, we commit to the following:

  • Acknowledge your report within 3 business days
  • Validate and triage the report, and give you an initial assessment, within 10 business days
  • Prioritize remediation by severity, aiming to fix critical and high-severity issues within 30 days and remaining issues within 90 days
  • Keep you informed of our progress, and let you know when the issue is resolved

We practice coordinated disclosure. Once an issue is fixed, we are happy for you to publish your findings, and we will credit you by name if you would like us to. If a vulnerability affects customer data, we will notify affected customers and, where required, the relevant supervisory authority without undue delay.

Rewards

Schedesk does not currently operate a paid bug bounty program, and we do not offer monetary rewards. We do offer our genuine thanks and public credit to researchers who report valid issues, if they wish to be named.

How We Protect Your Data

The safeguards currently in place across the Schedesk platform include:

  • Encryption at rest (AES-256) for all customer data, with additional application-level AES-256-GCM encryption for Slack and other OAuth access tokens
  • TLS 1.2 or higher for all data in transit, with HSTS enforced
  • Passwords stored only as bcrypt hashes; password reset and invitation tokens stored only as SHA-256 hashes
  • Strict per-company data isolation, so one workspace can never read another workspace's data
  • Role-based access control across the application and API, with server-side authorization on every request
  • Rate limiting, account lockout after repeated failed logins, and bot protection (reCAPTCHA) on authentication endpoints
  • A strict Content Security Policy with nonce-based scripts, CSRF protection, and the full set of OWASP-recommended security headers
  • Audit logging of authentication, administrative, and other security-relevant events, with alerting on high-risk activity
  • Regular dependency updates and vulnerability review of third-party packages

No system can be guaranteed to be completely secure. We continue to invest in improving our security posture, and reports from researchers are an important part of that.

Contact

For any security question, concern, or vulnerability report, email us at security@schedesk.com.

We use essential cookies for authentication and security. Optional cookies help us improve our service. Learn more