API Pentest - Temple

1. Introduction

Temple, a decentralized finance (DeFi) platform built on the Canton Network, commissioned a penetration test and automated security scan of its backend API. The engagement was performed by Halborn, Inc. The review targeted the orderbook-v2-do-NOT-apply-now branch of the temple-backend-api repository, at commit e88c6228ebb93e88609f0760b9166f97112e8479, hosted at https://github.com/Temple-Digital-Group/temple-backend-api/tree/orderbook-v2-do-NOT-apply-now.

The defined scope encompassed the public trading API endpoints, internal frontend-facing trading endpoints, API key self-service and administrative management endpoints, and the API key authentication mechanism. Key trading operations reviewed included order creation and cancellation, balance and trade history retrieval, withdrawal requests, and deposit and withdrawal history.

The purpose of this engagement was to identify security vulnerabilities, misconfigurations, and logic weaknesses across the authentication, session management, trading, and API key management surfaces of the Temple backend API prior to production deployment.

2. Assessment Summary

The engagement was scoped at a complexity level of 2 and spanned 18 days, during which Halborn specialist conducted a combined penetration test and automated scan of the Temple backend API. The primary objectives were to evaluate the security of trading endpoints, API key authentication flows, session and MFA management, and business logic controls.

The overall security posture of the assessed codebase revealed a significant number of findings spanning authentication, session management, cryptographic implementation, audit integrity, business logic enforcement, and privacy controls. While several fundamental security controls were correctly implemented, including transport security, SQL injection resistance, role separation, and cookie hardening; a broad set of weaknesses was identified that collectively represented meaningful risk to the platform's users, operators, and trading integrity.

The most important areas of remediation identified during the engagement include:

• Partial MFA session tokens being accepted on administrative, trading, bridge, settings, and wallet routes without full-session enforcement, allowing unauthenticated or MFA-incomplete identities to reach sensitive handlers.

• Missing balance, asset validity, order cap, minimum quantity, and trading-pause enforcement at order submission and withdrawal boundaries, undermining the integrity of core trading controls.

• Multiple authentication bypass and session-revocation weaknesses, including revoked partial MFA sessions completing login, email verification auto-login bypassing account lock checks, and stale KMS public keys continuing to validate revoked tokens.

• Audit log deficiencies including sensitive data persistence, incorrect authorization outcome fields, and incomplete sanitization of query parameters and case-variant field names.

• Cryptographic and entropy weaknesses including UUID generation panics on entropy failure, insufficient MFA backup code entropy, and a double-hashing defect in a KMS signing helper.

• Privacy and data handling issues including excessive email address logging across operational paths and incomplete user data erasure across ancillary tables.

• Cross-origin and CSRF control gaps on password reset endpoints, and query parameter injection in outbound CoinGecko API requests.

All of findings were marked as solved at the time of reporting, with one finding accepted as a known risk.