Skip to the content
← Back to the home page

Security

Last updated:

What protects the service and the data you entrust to it, measure by measure, and what we do not claim yet. If something here stops being true, this page changes first.

Where it runs

The application runs in containers rebuilt from source at each deployment; the database and the queues are not reachable from the internet.

In transit

  • Every page and every API call is served over HTTPS, with HTTP Strict Transport Security.
  • Every answer carries headers that forbid content sniffing and framing by another site, limit the referrer, and turn off the camera, microphone, location and payment features.
  • The web version of a campaign is served in a sandbox where no script runs, and the previews of an e-mail are sandboxed too.
  • The SMTP relay is reached over TLS on port 465. Toward a sending provider’s SMTP server, Lekalao uses TLS from the start on port 465 and STARTTLS on ports 25 and 587, and never sends in clear on those ports.

At rest

  • The credentials of sending providers, the secrets that sign webhooks and the private DKIM keys are encrypted in the database (AES-256, with the application’s key), and are never shown again once saved.
  • Passwords are stored only as bcrypt hashes. API tokens are shown once, when they are created, and stored only as hashes.
  • A transactional template can ask that the content of its e-mails not be kept.

Accounts and access

  • Nothing in the service is reachable before the account’s e-mail address is verified.
  • Two-factor authentication by an authenticator app, and passkeys. A team can require one or the other of every member.
  • Sign-in attempts are limited, and so is the API: 120 calls a minute per token by default.
  • Four roles: Owner, Editor, Writer, Viewer. Writing, sending and exporting are separate rights; a Writer prepares but neither sends nor exports.
  • Four eyes, if the team asks for it: a campaign leaves only once a member other than the one who asked approved exactly what will leave.
  • API tokens carry their own rights (read, write) and are revoked from the settings.

Who did what

Every action that changed something, every download that takes data out and every sign-in writes a line in the team’s activity log: who, what, to what, from which IP address, through the browser or which API token. Nothing anybody typed is kept in it. Owners can search it and export it; it is kept 400 days.

Protecting recipients and reputations

  • On the shared service, a team sends only from domains it has added and verified.
  • A campaign pauses by itself when its complaints or bounces cross the thresholds; addresses that bounced hard or complained are blocked for the whole team.
  • No marketing e-mail leaves without an unsubscribe link and a postal address.
  • Outgoing webhooks are signed with HMAC-SHA256. Payment notifications from the gateway are checked against their signature and a time window.
  • Addresses Lekalao fetches for a customer — feeds, webhooks, link checks — are refused when they point at the server itself, a private network or a cloud metadata address.
  • What a team writes on its public pages is escaped, and SVG images are refused.

Less data, kept less long

The IP address of an open or a click is not recorded, and no geolocation database is shipped. E-mail addresses are removed from error reports before they leave. Opens, clicks and delivery logs are deleted after 365 days, every night. Each team decides how long consent records and people who unsubscribed are kept, and can export or erase one person’s data from that person’s page.

Backups and recovery

The database and the stored files are backed up every night and kept away from the production server, encrypted, with at least seven daily and four weekly copies. The key that decrypts the stored credentials is kept with the same care as the database. A restoration is rehearsed every month on another machine: a session is opened, a provider’s credentials are read back, a subscriber’s data is downloaded.

How it is built

More than 1,000 automated tests and a static analysis of the code run on every change, in continuous integration.

Each team’s data is separated from every other team’s: every query is filtered by the team, the team is chosen before anything named in an address is looked up, and a signed-in request without a team is refused rather than answered. The tests start each request without a team, as in production, and try to reach another team’s lists, campaigns, subscribers, mailers and pages through the interface and the API.

What we do not claim

Lekalao holds no security certification (such as ISO 27001 or SOC 2) and has not yet had an external penetration test. It offers no availability commitment, and no single sign-on. When one of these changes, this page will say so, with the date.

Reporting a vulnerability

If you find a weakness, write to hello@lekalao.com with “Security” in the subject, and give us the time to fix it before you talk about it. Do not access, change or delete data that is not yours, and do not degrade the service. We answer every report, tell you what we did, and thank you by name if you wish.

Questions about this document: write to hello@lekalao.com