Skip to main content

​
What Lekalao does

​
Who may write in whose name

By default, a team may send with any sender address. That is convenient for a single organisation, and dangerous as soon as the installation holds several customers: one could write in another’s name, or a bank’s, from your providers and on your reputation.
.env
The sender address of a campaign, an automation e-mail, a transactional e-mail or a message from the SMTP relay must then be on a domain the team added and verified in Settings → Deliverability. Otherwise the send is refused, with a message that says why.
Switch it on before you open registration (Online-service mode).

​
Outgoing calls

Lekalao fetches addresses the teams give it: RSS feeds, outgoing webhooks, the automations’ “Call a webhook” action, link checking. Each address is resolved before the call, and refused when it points at:
  • the server itself (localhost, 127.0.0.0/8, ::1);
  • a private network (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, IPv6 local addresses);
  • a cloud metadata address (169.254.169.254).
Redirects are followed one at a time, under the same rule. Outgoing webhooks follow no redirect at all.

​
What is left to you

  • HTTPS everywhere, with HTTP redirected to it. Unsubscribe and preference links carry the subscriber’s identifier.
  • APP_DEBUG=false in production.
  • A firewall: only 80 and 443 open; PostgreSQL and Redis on 127.0.0.1 or a private network; the SMTP relay never exposed without TLS.
  • Updates of the OS, of PHP and of Lekalao.
  • Encrypted backups, with APP_KEY kept apart.
  • Proxies: behind a load balancer or Cloudflare, configure Laravel’s trusted proxies so that per-IP limits see the real address.
  • Accounts: require two-factor authentication of the platform administrators.

​
Reporting a vulnerability

Write to the security address of whoever supplied your Lekalao, without publishing the detail before it is fixed.