---
title: Security
description: What Sluurp does against the common attacks on web apps, and what is left to you.
section: Operations
order: 2
---

# Security

<p class="lead">The common attacks on a web app, as <a href="https://developer.mozilla.org/en-US/docs/Web/Security/Attacks">MDN lists them</a>, and what Sluurp does about each. Most of it needs nothing from you.</p>

## Cross-site scripting (XSS)

Text never becomes markup. JSX and `html` templates set text as text, so a name like `<img onerror=…>` shows as those characters. A `javascript:` URL in `href`, `src`, `action` and the like is replaced, however it is written. A string is never an event handler: `onclick="…"` is refused. The same rules hold on the server, where pages are rendered.

## Cross-site request forgery (CSRF)

A request is signed in by its `Authorization` header, never by a cookie. Another site can make the browser send a request, but it cannot add the header, so the request arrives as nobody's.

## Clickjacking

No HTML page can be framed by another site: every one is sent with `X-Frame-Options: SAMEORIGIN` and `frame-ancestors 'self'`. A page meant to be embedded elsewhere sets its own header, which is kept.

## Insecure direct object references (IDOR)

Ids are random, but that is not what protects a record. Every read and write goes through the collection's [rules](/docs/rules), checked in SQL, down to single fields, so knowing an id gives nothing the rules do not.

## Manipulator in the middle (MITM)

Serve behind TLS; see [Deploying](/docs/deploying). Once a browser reaches Sluurp over HTTPS, `Strict-Transport-Security` keeps it there for a year.

## Server-side request forgery (SSRF)

What Sluurp fetches on somebody's behalf — a function's `fetch`, a link preview, a post's card — only reaches public addresses. Loopback, private networks and cloud metadata addresses are refused, every redirect is checked, and the address checked is the one connected to, so DNS rebinding does not get round it. A function may reach more hosts through an allow list the superuser keeps.

## Prototype pollution

The server reads JSON with Rust types, which have no prototype. In the browser, what islands and RPC receive is parsed by devalue, which refuses a `__proto__` key.

## Cross-site leaks

Referrers stop at the origin across sites (`strict-origin-when-cross-origin`), and responses are never sniffed into another type (`nosniff`).

## Supply chain

Nothing is installed at run time. The server is one binary. Packages are [vendored](/docs/vendoring) byte for byte into `vendor/`, and served from there, not from a CDN, so what runs is what was reviewed and committed.

## Phishing and subdomain takeover

These are about people and DNS rather than code. Offer two-factor sign-in (see [Authentication](/docs/auth)), and remove a DNS record when the server it points at goes away.