Backend - Halborn One Scanner - Temple

1. Summary

2. Introduction

Temple engaged Halborn to conduct a Penetration Test on their systems, beginning on March 26th 2026 and ending on April 17th 2026. The security assessment was scoped to the components that Temple shared with the Halborn team. The assessment was a combination of Halborn One scanner and manual review.

3. Assessment Summary

The security review of the Temple Trading Engine reveals a system built on a sound architectural foundation, with the principal risk concentration in the operational layer that bridges the off-chain matching engine and the Canton distributed ledger. The defects identified are, without exception, edge-case activation paths: they require specific sequences of partial fills, concurrent operations, or infrastructure failures to manifest. None of them represent a trivially exploitable attack surface accessible to an external actor. The risk is operational, not existential: fund freezes and silent state divergence under stress, not adversarial fund extraction.

The compounding nature of several findings deserves attention at the executive level. Individual defects that are manageable in isolation interact to produce failure chains that are harder to detect and recover from: a rounding overflow in the fill loop misclassified as a maker-side error, triggering an eviction without fund release, against a background of incomplete audit coverage that leaves the sequence invisible to any post-hoc review. The remediation effort is best framed as a coordinated hardening of the settlement and matching paths, applied in a single pass to avoid partial remediation introducing new inconsistencies.

The review found no vulnerability that poses an existential risk to the platform or its users. There is no code path through which an external party could drain user funds, bypass the balance authorization model, or corrupt ledger state in a single exploitable action. The three-state balance model — unlocked, locked, in_flight — is a robust architectural decision that correctly constrains fund movement at each lifecycle stage. The Canton and DAML integration follows expected patterns for distributed ledger command submission, and the codebase demonstrates clear domain expertise in exchange mechanics. The findings reflect the difficulty of edge-case coverage in a complex system, not a lack of engineering discipline.

4. Assessment Summary

The Halborn Team were allocated 12 business days for this engagement, during which two full-time security engineers - experts in blockchain, web, and API security - conducted a comprehensive audit of the in-scope components related to Temple systems. These engineers possess advanced skills in penetration testing, web application security assessments, and an in-depth understanding of multiple blockchain protocols.

The primary objectives of this audit were to:

• Verify that each component performs its intended functions accurately and reliably.

• Identify and assess potential security issues within the application, particularly those that could impact the management and protection of Temple.

Additional objectives included evaluating adherence to industry best practices, ensuring robust security measures are in place, and identifying opportunities for further strengthening the security posture.

The security assessment of the Canton Tokenization Service application revealed a platform with a solid foundational architecture that carried several security gaps requiring remediation before production deployment. The most severe issue identified was the use of a weak, hardcoded JWT secret for authentication. This finding was resolved after the development team confirmed that the HS256 "unsafe" mode was solely an artifact of the test environment and is not used in any production deployment, where authentication relies on RS256 with a proper OIDC provider.

However, closely related concerns were also identified: JWT tokens lacked proper expiration enforcement and the logout function did not invalidate active sessions, meaning that stolen or leaked tokens remained usable indefinitely. These authentication and session management weaknesses collectively represented the highest-priority remediation area.

Beyond authentication, the application exhibited a pattern of insufficient operational hardening. The backend streaming service logged raw transaction payloads at debug level, creating a passive data leakage channel through log aggregation — a meaningful concern where transaction details constitute sensitive financial data. The CORS policy was overly permissive, the API lacked rate limiting, and session state was managed client-side in a volatile manner susceptible to inconsistency and manipulation. Together, these indicated that security controls were designed primarily around the DAML contract and ledger layer, with the HTTP and infrastructure layers treated as secondary rather than independent defense boundaries.

On the data handling side, the CSV export functionality lacked input sanitization, leaving it susceptible to formula injection when exported files were opened in spreadsheet applications. Although rated informational, this remained practically relevant given that operators and investors working with financial instruments routinely open exported CSVs in Excel.

Remediation priorities centered on three areas: enforcing JWT expiration and implementing proper token invalidation to close the authentication lifecycle gaps; reducing logging verbosity for sensitive payloads, tightening CORS, and introducing rate limiting; and sanitizing CSV output while moving session-critical state server-side. The underlying architecture provided a strong security foundation, and the fixes needed were implementation-level adjustments rather than architectural rework.The security assessment of the Canton Tokenization Service application revealed a platform with a solid foundational architecture that carried several security gaps requiring remediation before production deployment. The most severe issue identified was the use of a weak, hardcoded JWT secret for authentication. This finding was resolved after the development team confirmed that the HS256 "unsafe" mode was solely an artifact of the test environment and is not used in any production deployment, where authentication relies on RS256 with a proper OIDC provider.

However, closely related concerns were also identified: JWT tokens lacked proper expiration enforcement and the logout function did not invalidate active sessions, meaning that stolen or leaked tokens remained usable indefinitely. These authentication and session management weaknesses collectively represented the highest-priority remediation area.

Beyond authentication, the application exhibited a pattern of insufficient operational hardening. The backend streaming service logged raw transaction payloads at debug level, creating a passive data leakage channel through log aggregation — a meaningful concern where transaction details constitute sensitive financial data. The CORS policy was overly permissive, the API lacked rate limiting, and session state was managed client-side in a volatile manner susceptible to inconsistency and manipulation. Together, these indicated that security controls were designed primarily around the DAML contract and ledger layer, with the HTTP and infrastructure layers treated as secondary rather than independent defense boundaries.

On the data handling side, the CSV export functionality lacked input sanitization, leaving it susceptible to formula injection when exported files were opened in spreadsheet applications. Although rated informational, this remained practically relevant given that operators and investors working with financial instruments routinely open exported CSVs in Excel.

Remediation priorities centered on three areas: enforcing JWT expiration and implementing proper token invalidation to close the authentication lifecycle gaps; reducing logging verbosity for sensitive payloads, tightening CORS, and introducing rate limiting; and sanitizing CSV output while moving session-critical state server-side. The underlying architecture provided a strong security foundation, and the fixes needed were implementation-level adjustments rather than architectural rework.