Ihawu

Ihawu (Ndebele for shield) guards the data your API returns. It is a lightweight Policy Enforcement Point: you annotate a field, define a policy, and every response is masked for the caller who receives it — enforced as the response is serialized, and failing closed rather than leaking on error.

The problem

Sensitive data leaks through responses

SSNs, salaries, and PII slip into API payloads because masking is an afterthought bolted onto controllers.

Masking logic sprawls

if (role == ...) checks scatter across handlers, DTOs, and mappers — hard to audit, easy to get wrong.

Reinvented per framework

Every service and platform rolls its own masking, with no shared, testable enforcement layer.

Why Ihawu

Declarative

Annotate a resource with @IhawuResource and describe rules as policy — no masking code in your controllers.

Fail-closed by default

No verified identity? Ihawu emits {} rather than leaking. Security is the default, not an opt-in.

Serialization-neutral core

The core carries no web-framework or serialization dependency — backends and adapters sit on top. It is multiplatform (JVM + JS): mask through Jackson or kotlinx.serialization.

Your policy source, your call

Static rules in config, or dynamic ones from a database or OPA via a simple SPI. Ihawu enforces — it never usurps your decision engine.

Already using Jackson’s @JsonView or @JsonFilter? They solve part of this, and for a small enough problem they are the right answer. How Ihawu compares →

Adapters

Spring Boot Starter — available

Drop the starter on the classpath and Ihawu auto-configures masking into your Jackson pipeline. Get started →

Ktor — available

One install(IhawuKtor) masks every @IhawuResource response per caller role, with no per-route code. Ktor adapter →

Kotlin Multiplatform — available

ihawu-kotlinx masks through kotlinx.serialization on the JVM and JS, through the same serialization-neutral engine. How it works →