In today’s complex and regulated environment, our users entrust us to protect their data using industry-standard tools and practices. This article gives an overview of the multi-layer, "defense in depth" efforts made by Skedda to meet these requirements.

We begin with the persistence layer. We encrypt the storage of our entire primary application database, its associated backups and its transaction log files "at rest". This security feature involves the use of so-called "Transparent Data Encryption". The encryption uses an industry-standard, FIPS 140-2 validated, AES-256 symmetric encryption key. This key is protected by a certificate that is rotated at least every 90 days. This approach is a requirement of many industry standards (e.g., HIPAA, PCI). It also a key technical factor for our compliance with the EU GDPR (applicable from May 2018).

We further secure our persistence layer by limiting access to our primary application database to the application layer and a fixed set of known Skedda-owned IP addresses. This access-limitation is achieved using a combination of firewall rules, authentication mechanisms (requiring users to prove their identity), and authorization through role-based memberships and permissions.

We address the possibility of a catastrophic application data-loss (e.g. as a result of a natural disaster) by automatically creating database backups using a geo-redundant approach. We create full, differential and transaction-log backups, each of which are encrypted as discussed above. Full database backups happen weekly, differential database backups generally happen every few hours, and transaction log backups generally happen every 5 - 10 minutes. In the event of data-loss, we are able to restore our database to a specific point in time to minimize lost information. Backups are retained for a period of 35 days and then destroyed.

To help us maintain regulatory compliance, understand database activity, and gain insight into discrepancies and anomalies that could indicate suspected security violations (another aspect of the EU GDPR), we have deployed three advanced security features on our primary application database servers:

  • Advanced Database Auditing helps Skedda maintain regulatory compliance, understand database activity and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violation. Database audit logs are retained for a period of 35 days and then destroyed.
  • Advanced Threat-Protection Monitoring detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit the Skedda production database. It continuously monitors the production database for suspicious activities, and provides immediate security alerts to the Skedda operations team on potential vulnerabilities, SQL injection attacks, and anomalous database access patterns. In the particular case of the GDPR, this service forms a key part of the technical machinery which enables us to detect data breaches and notify supervisory authorities in the unlikely event that one should occur. 
  • Automated Periodic Vulnerability-Assessment Scans proactively discover and track potential database vulnerabilities, triggering alerts when required so that the Skedda operations team can resolve them quickly. Scans are run on a weekly basis.

Between our persistence layer and the application layer, we secure your "in flight" data by providing encryption using the industry-standard Transport Layer Security cryptographic protocol (TLS 1.2).  The database server's certificate is validated in this process (the server name of the database SSL certificate must exactly match the server name specified by the application layer, otherwise the connection attempt is aborted).

At the application layer, we force all inbound requests to use secure HTTPS (HTTP over TLS) connections. The connection must use TLS 1.2 or higher (i.e. we forbid connections using the outdated TLS 1.1 and TLS 1.0 protocols, and also the outdated and vulnerable SSL 2 and SSL 3 protocols). We also support HTTP/2 for improved performance.

The accepted TLS connections are encrypted using an SSL certificate using one of the strongest web standards available (256-bit Elliptic Curve Cryptography key). The signature algorithm is based on SHA-256 with RSA encryption. Only modern cipher suites are configured, like ECDHE_ECDSA with AES_256_GCM.

To help ensure that only our trusted Certificate Authorities can issue a certificate for *, and hence to help prevent the misuse of certificates in some circumstances, we have an active DNS Certification Authority Authorization (CAA) record. It's now mandatory for certificate authorities to implement CAA-checking, and our CAA record will prevent unauthorized CAs from issuing certificates for *

As part of all responses, our servers include a number of advanced security headers. These include but are not limited to:

  • X-XSS-Protection: Instructs modern browsers to abort communications when they detect reflected cross-site scripting (XSS) attacks.
  • Content-Security-Policy: Instructs browsers to take strict measures to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. Specifically, we have deployed a so-called "strict CSP3 policy" using the state-of-the-art "nonce" and "strict-dynamic" options.
  • Strict-Transport-Security: Also known as HSTS. Instructs browsers to only ever access Skedda using HTTPS (i.e. never using HTTP). We have deployed this header with a long duration/time-to-live (one year), and we're also on the HSTS preload list (see below).
  • X-Content-Type-Options: Instructs browsers to strictly follow the MIME types ("Content-Type") specified in server responses, and not to try to "sniff" the content type. This helps to defend against MIME content-sniffing attacks.
  • Expect-CT: Tells a web client/browser to enforce Certificate Transparency requirements (i.e. checking that our site certificates appear in public CT logs), which helps prevent the use of misissued Skedda certificates.
  • Referrer-Policy: Allows us to control the value of the "referer" (sic) header for links away from our pages. In our case we specify that the "referer" header should not be set when the navigation results in a downgrade from HTTPS to HTTP.
  • X-Frame-Options: Unless explicitly allowed by a venue administrator, this header prevents browsers from rendering Skedda pages in other sites (using e.g. frames and objects). This helps to avoid "clickjacking" attacks.

Skedda receives an "A" grade from the independent, industry-standard security-header-checking service You can run the test on demand and view the report for yourself. We also encourage you to run the test against other websites you may be using or you may be intending to use. We have automated tests in place to detect regressions from our "A"-grade state.

The Skedda application-hosting servers also receive an "A+" grade from the independent, industry-standard Qualys SSL Labs server test. You can run the test on demand and view the report for yourself. The report notes that we're not vulnerable to some of the more recent vulnerabilities like BEAST, POODLE and Heartbleed. Again we encourage you to run the test against other websites you may be using or you may be intending to use.

Our full domain (including all subdomains) is on the HSTS Preload List for direct inclusion as a "HTTPS-only service" in modern browsers. This "hard-coding" of our full domain in browsers ensures that they will never attempt to connect via insecure HTTP. To verify for yourself that that is included in this list, you can visit (e.g. in Chrome) chrome://net-internals/#hsts and query the HSTS list for "".

Our full domain has additionally enabled DNSSEC to ensure that DNS records are not tampered with. You can view the security details of our DNS setup here.

On the client layer, we use industry-standard techniques to help prevent phishing and hacking attacks. For example, we use the Synchronizer token pattern to fight cross-site request forgery, and validate all user-input for HTML/script and injection. To help prevent dictionary attacks, our login mechanism additionally employs account lock-out functionality if an incorrect login password is entered multiple times. We also employ a strong password policy: all Skedda passwords must have 1) at least one lowercase character, 2) at least one uppercase character, 3) at least one digit and 4) at least a length of eight characters.

The cookies sent from the server to the client for authentication and request-verification purposes are always marked with "HttpOnly" and "Secure" attributes, and have their domain and path values appropriately set for use with Skedda.

We prevent the forgery of authentication and request-verification cookies by using an advanced data-protection mechanism. The default payload protection algorithm used is AES-256-CBC for confidentiality and HMACSHA256 for authenticity. A 512-bit master key, rolled automatically every 90 days, is used to derive the two sub-keys used for these algorithms on a per-payload basis. The key store is only accessible through a HTTPS connection using a connection string that is configured directly on and only visible by the production Skedda web application.

With respect to online payments, Skedda is PCI compliant. In practice, all payments are processed directly with your chosen payment gateway. As such, no sensitive payment details ever make contact with Skedda-owned systems (it is instead transparently redirected to your gateway and then managed through a token-based approach). Our primary payment-gateway provider Stripe has further details on their security page:

The transactional emails sent by Skedda make use of the latest security features for email validation. These include valid SPF, DKIM and DMARC policies. In the case of DMARC, our published policy instructs recipient servers to quarantine all messages that don't pass the DMARC test. These features are advanced tools help to prevent spamming, spoofing and phishing attacks. Naturally we also include unsubscribe links on all the emails we send, and have implemented rate-limiting to help prevent annoying "mailbombing" attacks.

At the organizational layer, Skedda employees have restricted access to your data based on the "need to know" and "least privilege" security principles. Development and test systems exist on an in-house network that is not externally accessible. Our application source code is managed in a private repository and includes no sensitive information (like API keys, passwords or connection strings) - all such information is stored securely in a key vault within the hosting environment.

In the case of any incidents (e.g. application outages, degraded performance or similar), we provide real-time updates at General application news and updates are provided at

Finally, we regularly contract independent penetration testers to evaluate the security at Skedda, and quickly respond to any security-related questions and issues. 

We hope that this article has helped you to understand the security mechanisms in place at Skedda. We continuously review our security procedures, so this article may well change in the future as we respond to the evolving security landscape. As always, we invite you to reach out to our support team if you have any questions.

Did this answer your question?