Security
Some of what makes a site built with Inka easier to keep secure comes from being headless at all, and you get it with any headless CMS. Some of it is particular to Inka. This page keeps the two apart.
What any headless site gets
In a traditional CMS, the site visitors use is the same application editors log in to. The login page, the editing screens and the interfaces that change content can all be reached by anyone on the internet, and a flaw in any of them is a flaw in the public site.
A headless site splits that in two. The public site is a separate application that only reads published content, and the CMS where editors work can be kept off the public internet. That follows two long-standing security principles: shrink the attack surface by removing what an attacker could reach and does not need to (OWASP Attack Surface Analysis Cheat Sheet), and protect administration interfaces so that only authorised people can reach them (NCSC, secure system administration). A public site that is built as static pages, or served from a cache, has less still to attack.
Headless does not remove every risk; it moves some of it. The content API the public site reads from becomes the main way in, so it should serve published content only, without the ability to change anything. A site built as static pages needs no live connection to the CMS at all.
What Inka adds
An editor you can lock down
SaaS headless products such as Contentful, Sanity and Storyblok give you the headless split, but the editor and the content store are the vendor's service, on the public internet and shared with the vendor's other customers. Who can reach the login, where your content is held and how it is kept apart from other customers' content are for the vendor to decide, within what your plan offers. The vendor also becomes part of your supply chain: a flaw or breach on their side is one on yours. These are the questions the NCSC's cloud security principles ask you to answer about any such service, under "Separation between customers" and "Supply chain security".
Inka runs on your own infrastructure, or on an instance of its own that we run for you. It sits behind a login that you can restrict to your own network, a VPN or a list of IP addresses, and the content stays in your CMS, on infrastructure you choose.
A standard CMS that is quick to patch
A security fix only protects you once it is applied, and what usually slows that down is customisation. A headless site built on an open-source CMS still tends to keep its page building inside the CMS: custom blocks, page-builder plugins and templates. Each of them has to be checked against every new release, and often rewritten, before the release can go live.
Inka keeps that work out of the CMS. Your design system's blocks, templates and rules live in the frontend, and the adapter that connects Inka to the CMS is a plugin in Inka, not in the CMS. In most cases the CMS runs as it ships, with nothing of yours inside it. So a CMS security release can be applied as soon as it comes out, with little risk of breaking the site, and major versions are cheaper to move to, because there is no custom code to port. The frontend has its own release cycle and can be upgraded without waiting for the CMS.
No editing code on the public site
Visual editing usually needs a script running inside the site being edited. Inka loads its editing script only while someone is editing, so the public site does not carry it.
Open source throughout
Inka is open source under the MIT licence, and so are the CMSs it works with and the frameworks its frontends are built on. Anyone can read the code, and far more people do than any single vendor employs, so flaws are more likely to be found, and fixes are published for everyone. The CMSs each have their own security team, which takes reports privately and publishes advisories with each fix. A SaaS product's code is closed: you rely on the vendor alone to find and fix its flaws.
Security fixes to fixed timescales
Report vulnerabilities in Inka privately to security@pretagov.com. The security and maintenance subscription covers security fixes on the version you run: critical and high within 14 days, actively exploited within 72 hours, with advance notice of security releases.