Security

We teach cloud and security engineering, so we hold our own systems to the standard we teach. That means least privilege by default, encryption everywhere, private networking, and no shared administrative credentials.

This page describes the controls we actually run, not aspirations. Where we do not yet do something, we say so.

• All traffic to our website and API is served over HTTPS with TLS 1.2 or higher. Plain HTTP requests are redirected.
• Application servers run in private subnets with no public IP addresses. Administrative access is through a session-managed channel, not open SSH ports.
• Our database is private, encrypted at rest, unreachable from the public internet, and reachable only from the application security group.
• Automated database backups are retained daily and deletion protection is enabled.
• Media files are served through a content delivery network from a private origin bucket that cannot be read directly.
• Infrastructure is defined as code and reviewed before it changes, so configuration drift is visible.

We never see, transmit or store card numbers. Card details are entered directly into Stripe’s hosted checkout, which is certified as a PCI DSS Level 1 service provider.

What we store is the outcome: an amount, a currency, a status, a plan type and a Stripe reference identifier. A breach of our database would not expose anyone’s card.

Payment webhooks from Stripe are signature-verified before we act on them, so a forged webhook cannot mark an unpaid enrolment as paid.

• Passwords are hashed with bcrypt. We never store them in a form we could read, and we cannot tell you your password.
• Sessions use HttpOnly, Secure cookies that scripts on the page cannot read.
• Email addresses are verified before an account is fully active.
• Password reset links are single use and expire shortly after they are issued.
• Access to learner records is role-based. Instructors see their own cohorts. Administrative access is limited to the people who need it.
• Administrative and cloud accounts require multi-factor authentication.

Learner data is encrypted in transit and at rest. Production data is kept separate from development and test environments, and we do not copy real learner records into a development database.

Secrets, credentials and environment configuration are stored in an encrypted parameter store rather than in the repository, and are injected at deployment time. No production secret is committed to source control.

Retention periods for each category of data are set out in our Privacy Policy.

We log application errors, authentication events and administrative actions, and we review anomalies. Logs are retained for 90 days.

If an incident affects personal information, we investigate, contain it, and notify affected learners and the relevant regulators within the timeframes required by applicable state breach notification laws. Our notification will say what happened, what data was involved and what you should do.

We keep the number of providers with access to learner data deliberately small: a payment processor, a cloud hosting provider, a transactional email provider and a video conferencing provider. Each is reviewed before we adopt it, and each is bound by a data processing agreement.

We do not embed advertising, analytics or session replay scripts from providers that would receive learner data.

• Use a unique password for your Upkora account, ideally from a password manager.
• Do not share your account. Every enrolment is for one person, and shared access is the most common cause of account compromise.
• Check that any email asking you to sign in or pay actually comes from our domain, and go to the site directly rather than following a link if you are unsure.
• Tell us immediately if you think someone else has accessed your account.

We will never ask for your password, a payment card number or a verification code by email, chat or phone. Any message that does is not from us.

If you have found a security issue in our website, API or infrastructure, email the security address on this page with enough detail to reproduce it. Include the URL or endpoint, the steps, what you were able to access and any proof of concept.

In scope

upkoraacademy.com, api.upkoraacademy.com, admin.upkoraacademy.com and media.upkoraacademy.com.

Out of scope

Findings from automated scanners without a working proof of concept, missing best-practice headers with no exploit, rate limiting on non-sensitive endpoints, social engineering of our staff or learners, physical attacks, denial of service, and vulnerabilities in third-party services we do not control.

Please test only against your own account, use the smallest amount of access needed to demonstrate the issue, and stop as soon as you have confirmed it. Do not access, modify, download or retain data belonging to another person. Do not run denial of service tests or automated scans that degrade the service. Give us a reasonable opportunity to fix the issue before you disclose it publicly.

If you follow the rules above in good faith, we will treat your research as authorised, we will not pursue legal action against you, and we will not report you to law enforcement. If a third party brings a claim against you for research that followed this policy, we will make it known that you were acting within it.

1. 01We acknowledge your report within 3 business days.
2. 02We confirm whether we can reproduce it and give you a severity assessment within 10 business days.
3. 03We keep you updated while we work on a fix and tell you when it ships.
4. 04We are happy to credit you publicly once the fix is live, if you want that.

We do not currently run a paid bug bounty, so there is no monetary reward. We say that up front rather than after you have spent your time.