GUIDELINE 05
Build third-party off-chain connections carefully
Browsers can call CORS-enabled public services, but API secrets and privileged integrations belong behind a controlled server boundary.
Boundary rules
- Never embed third-party secrets in JavaScript; users can always inspect them.
- CORS is permission from the remote service, not authentication and not a security boundary for your backend.
- Send the minimum request to your backend. Apply authentication, rate limits, timeouts, size limits, and replay protection there.
- Return a narrow, signed or otherwise verifiable result when a contract must rely on off-chain work.
- Define what happens when the provider is slow, unavailable, or returns conflicting data.
Prefer native client proofs where they fit
The CDN PoW flow performs the expensive work locally without exposing a server secret: request a token, perform work in a worker, submit the solution, then claim it directly or pass its token ID to a contract call.
Proof-of-work lifecycle
const token = await itza.pow_request_token(
wallet.keypair, applicationAddress, commitment, 10, CLUSTER_ID
);
const tokenId = token.signature;
const solution = await itza.pow_perform_work(token, (fraction, detail) => {
showProgress(detail.phase, Math.round(fraction * 100));
});
await itza.pow_submit_completed(wallet.keypair, tokenId, solution, CLUSTER_ID);
await itza.pow_submit_claim(wallet.keypair, tokenId, CLUSTER_ID);
const finalToken = await itza.pow_get_token(tokenId, CLUSTER_ID);Bottom line
Keep trust-sensitive work server-side or cryptographically verifiable, and design every external dependency as an unreliable dependency.