Security
Schools, colleges and universities usually ask for a security review before a tool is installed
in their learning platform. This page answers the questions of the
EDUCAUSE
Higher Education Community Vendor Assessment Toolkit (HECVAT), Lite edition, area by area, for
fxEditor, fxTeX Server, the plugins, the LTI tool (lti.codecogs.com) and this website. Where the
answer is no, we say so.
A completed HECVAT spreadsheet is available on request. Email
support@codecogs.com
or use the contact form. We will also complete your institution's own
questionnaire.
See also the Privacy Policy,
Student Data Privacy and the
Accessibility Conformance Report.
Company
| Question | Answer |
|---|
| Legal name | Zyba Ltd, trading as CodeCogs; registered in England and Wales, company
number 5190331 |
| In business since | 2004; the equation editor since 2005 |
| Number of employees | [[TODO]] |
| Security contact | support@codecogs.com
[[TODO: a named security lead]] |
| Cyber insurance | [[TODO]] |
| Data breaches in the last three years | [[TODO]] |
Documentation and assessments
Hosting and data centre
| Question | Answer |
|---|
| Where is the service hosted? | Vultr, in New York, United States. Two servers run the
services as containers (Docker Swarm), behind a Vultr load balancer. |
| Where is institutional data stored? | In the United States, on those servers. We do
not offer a choice of region. |
| Data centre certifications | Those of Vultr [[TODO: link Vultr's compliance page and
confirm the New York facility's certifications]] |
| Shared or dedicated | Cloud servers dedicated to CodeCogs services; institutions'
data is separated logically, in shared databases, not physically. |
| Redundancy | The rendering service runs as several copies across both servers, so
either server can fail without interrupting it. [[TODO: the website and LTI tool — how many
copies, on which servers]] |
| Uptime commitment (SLA) | [[TODO: none published, or state it]] |
Authentication
| Question | Answer |
|---|
| How do users of the LTI tool sign in? | Through their learning platform, by LTI 1.3
(1EdTech LTI Advantage security framework). The platform starts an OpenID Connect login; the
tool receives a signed JSON Web Token (JWT), verifies its signature against the platform's
published keys, and checks its issuer, audience, nonce and expiry. The tool has its own RSA key
pair for each platform, publishes its public keys (JWKS), and signs the Deep Linking response that
returns the equation. There are no separate accounts or passwords for the LTI tool. |
| How do customers sign in to this website? | With a single-use link emailed to them,
or a passkey (WebAuthn/FIDO2). No passwords exist to be stolen or reused. Sessions end after 3
days without use. |
| Institutional single sign-on (SAML, OIDC) for this website | No. Microsoft sign-in is
used for our Office add-in only. |
| Multi-factor authentication | Passkeys are phishing-resistant and bound to the user's
device. Multi-factor sign-in is not enforced for any account, including administrators. |
| Do the editor, plugins and rendering service authenticate end users? | No. They
identify the licence, by licence key or by the registered website domain, not the person. |
Application security
| Question | Answer |
|---|
| Security headers | HTTP Strict Transport Security; X-Content-Type-Options:
nosniff; a strict referrer policy; framing blocked on account, payment and administration
pages. A Content Security Policy: No. |
| Cross-site request forgery | Requests that change data must come from our own site,
checked by their origin; third-party callbacks (payment notifications) are verified by signature
instead. |
| Abuse protection | Rate limits on sign-in, sign-up, feedback and rendering, per
address and per licence; reCAPTCHA on the contact, purchase and enterprise forms. |
| Administrative access | Limited to CodeCogs staff marked as administrators. Changes
an administrator makes to a customer's licence are recorded against it, with who made them. |
| Secure development practices | All code is in version control; database changes are
scripted migrations. [[TODO: code review, dependency scanning, static analysis — Yes/No]] |
| Vulnerability management | [[TODO: how and how often operating systems, container
images and libraries are patched; whether vulnerability scanning is done]] |
| Reporting a vulnerability | Email support@codecogs.com
with “Security” in the subject. |
Data security
| Question | Answer |
|---|
| What institutional data is held? | For the LTI tool: the platform's registration
(issuer, client id, deployment id, its key addresses), usage counts per deployment, and launch
data for at most 24 hours — an opaque user id, roles and course id. No names, email
addresses, rosters or grades are requested. Equations are embedded in the institution's own
course pages. See Student Data Privacy for the
full list. |
| Encryption in transit | Yes. Every public service is HTTPS only (TLS 1.2 and 1.3);
plain HTTP is redirected. Traffic between our own containers and to the database stays on our
servers' private network and is not separately encrypted. |
| Encryption at rest | No — databases and logs are not encrypted at rest by us.
[[TODO: confirm whether Vultr encrypts the underlying disks]] |
| Payment card data | None held. Cards are entered into Stripe's own form and go
straight to Stripe, which is PCI DSS Level 1 certified. |
| Passwords | None held (see Authentication). |
| Logging | The rendering service records each request with the reader's IP address
anonymised before it is written. Web servers log failed requests. Daily usage counts are kept per
licensed site. |
| Backups | [[TODO: what is backed up, how often, where to, whether encrypted, how long
kept, and when a restore was last tested]] |
| Data used for other purposes (advertising, sale, AI training) | No. See the
Privacy Policy. |
Third parties
| Provider | Role |
|---|
| Vultr | Hosting (servers, load balancer, storage) |
| Stripe | Payments, for customers who buy a licence online |
| Microsoft | Our outgoing email (Microsoft 365); Office add-in sign-in |
| Google | reCAPTCHA on some of this website's forms; ads on this website's home page.
Not used by the LTI tool, the plugins or the rendering service. |
No institutional or student data from the LTI tool is shared with any of them except Vultr, as
our host.
Change management
Changes are made in version control. Each release is given a version number, built into a
tagged container image and deployed to the servers by Docker Swarm, which replaces the running
copies; a release can be rolled back by redeploying the previous image. Changes that affect how
institutions use the LTI tool or the plugins are announced on our
plugins site [[TODO: confirm, and how much notice is given]].
Incident response
| Question | Answer |
|---|
| Documented incident response plan | [[TODO: Yes/No]] |
| Breach notification | We will notify affected institutions without undue delay, and
within 72 hours of confirming a breach of their data, with what is known and what we are doing;
and the UK Information Commissioner's Office where the law requires. Where an institution's
agreement with us sets a shorter period, that applies. |
| Business continuity and disaster recovery plan | [[TODO: Yes/No; recovery time and
recovery point objectives]] |
Retention and deletion
- LTI launch data is deleted automatically within 24 hours.
- When an institution ends its licence or asks us to, we delete its LTI registration and the
personal data we hold for it [[TODO: within how many days]], and confirm in writing. Usage
counts with no personal data, and invoices, are kept as the
Privacy Policy says.
- Equations already placed in course pages belong to the institution and stay in its learning
platform. An equation inserted as an image is loaded from our rendering service each time the
page is viewed, so it relies on that service remaining available.
