Security

Reporting a vulnerability

Please do not open a public issue for a security report.

• Email: security@rakomi.com

The rakomi_flutter package’s security policy adopts the terms — response targets, coordinated-disclosure conditions, safe harbor, what to include in a report, and how reporter personal data is handled — of the shared Rakomi SDK security policy, published in the JavaScript-family SDK repository. If you are reporting a vulnerability in this package, email is the channel to use. Full terms ship with the package as SECURITY.md.

Scope. In scope: the rakomi_flutter package’s source, its published releases, and the authentication and credential-handling logic it performs on the device. Out of scope: the Rakomi platform itself, the JS-family SDKs (covered by their own policy), and third-party dependencies (report those to their maintainers).

Transport security

RakomiProvider(apiBaseUrl:) requires https://. Exactly one exception exists, for local development, and it is enforced in the constructor — see Configuration → Validation. Any other http:// URL is rejected with an ArgumentError before the provider is built.

Optional certificate pinning (RakomiProvider(certificateFingerprints:)) applies to https:// requests to non-loopback hosts on iOS and Android. On Web it is ignored — transport security there is the browser’s.

Threat model

The SDK’s defenses are described in terms of what they cover, so you can reason about the gap between that and your own app’s responsibilities:

• Rooted/jailbroken device — secure-storage extraction is possible on a compromised device. Mitigating this is the consuming app’s responsibility (device-integrity/root-detection tooling).
• Device with no passcode set — on a stolen device that has never had a passcode, stored credentials remain readable once the device has been unlocked at least once. The SDK surfaces BiometricUnavailable(reason: 'no_device_passcode') so your app can react. Credentials are stored device-only and are therefore not carried into a cloud device backup.
• Screen-overlay / clickjacking (Android) — consumer apps should set FLAG_SECURE on the auth activity.
• Keylogging — outside the SDK’s threat model; biometric paths bypass password entry on supported platforms.
• App-switcher screenshot leakage — consumer-app responsibility: set the platform’s screenshot-prevention flag while authenticated state is visible.
• Network interception on managed/hostile networks — mitigated by the optional certificate pinning described above.

Web security considerations

Flutter Web does not have OS-level secure storage. The default adapter’s secure-storage plugin falls back to browser storage protected with per-origin encryption — this is not the same guarantee as an OS keystore: a successful XSS against your app can still read the token. Mitigations:

• A strict Content-Security-Policy (no inline script execution).
• Trusted-Types enforcement if your bundler emits DOM sinks.
• Treat Web sessions differently from mobile: shorter token lifetimes and more aggressive refresh.

Custom URL scheme caveats

On Android, a custom URL scheme is first-come-first-served at the OS level, so a malicious sibling app could in principle register the same scheme and intercept an OAuth callback. See Installation for the mitigation (Android App Links) and its current status.

What the SDK does NOT do

• It does not log tokens.
• It does not collect device telemetry by default.
• It does not issue cookies — it is a Bearer-token client, so there is no SDK-level CSRF surface to defend.
• It does not auto-forward lifecycle events to any sink — see Session & tokens → Audit events.

Stability and versioning

While rakomi_flutter is on its 0.x line, adapter-interface changes are additive-only; a breaking adapter change ships as a minor bump (0.1.x → 0.2.0) with a migration note. See the package CHANGELOG.md for the full stability policy and the version history.