ذرائع کی جانچ پر مبنی تحقیق: Binance / OKX / Coinbase

Verified source facts

1. Binance documentation recommends IP restrictions and limits unrestricted HMAC keys to reading unless security controls are changed. 2. OKX documentation describes Read, Trade, and Withdraw permissions, IP allowlists, and deletion of certain inactive unbound keys. 3. Coinbase developer documentation separates API-key authentication from permissions and secret handling for developer applications. 4. OWASP recommends centralized secrets management, restricted access, rotation, auditing, and avoiding secrets in source code.

Comparison at a glance

1. Control test: Default privilege

An API-security disclosure is meaningful only when converted into a testable control. For default privilege, inspect what a newly created key can do. Create a key in a non-production or least-privileged context where available, then start read-only and add one permission at a time. Capture the permission screen without recording the secret, and verify that a forbidden operation is actually rejected.

Model the failure path, not just the setup path. Ask how a leaked credential could be used, what network restriction would stop it, which log would reveal the attempt, and how quickly the key could be revoked. Platform documentation describes supported settings; it cannot prove that a user or vendor configured them correctly. In this dimension, undocumented internal safeguards is therefore an explicit audit gap.

Score disclosures separately from security outcomes. Clear documentation, restrictive defaults, IP binding, asymmetric signing, expiration, and audit visibility are positive signals. They do not certify the exchange, the third-party bot, or the operator's endpoint. The useful output is a remediation list tied to permissions and owners.

2. Control test: Withdrawal authority

For withdrawal authority, inspect whether an API can move assets externally. Create a key in a non-production or least-privileged context where available, then leave withdrawal disabled for analytics and bots.

In this dimension, account-specific override paths is therefore an explicit audit gap.

3. Control test: IP binding

For ip binding, inspect network-level restriction of requests. Create a key in a non-production or least-privileged context where available, then allowlist fixed trusted addresses.

In this dimension, protection when upstream IPs change is therefore an explicit audit gap.

4. Control test: Key type

For key type, inspect HMAC versus asymmetric credentials. Create a key in a non-production or least-privileged context where available, then prefer supported asymmetric signing for durable systems.

In this dimension, future platform deprecation is therefore an explicit audit gap.

5. Control test: Storage

For storage, inspect where secrets live at rest. Create a key in a non-production or least-privileged context where available, then use a secret manager rather than code or spreadsheets.

In this dimension, operator handling outside the system is therefore an explicit audit gap.

6. Control test: Logging

For logging, inspect risk of leaking headers or signatures. Create a key in a non-production or least-privileged context where available, then redact secrets and test logs.

In this dimension, third-party telemetry retention is therefore an explicit audit gap.

7. Control test: Rotation

For rotation, inspect changing credentials without downtime. Create a key in a non-production or least-privileged context where available, then maintain a tested overlap and revocation procedure.

In this dimension, emergency rotation speed is therefore an explicit audit gap.

8. Control test: Monitoring

For monitoring, inspect detection of unusual API use. Create a key in a non-production or least-privileged context where available, then alert on new IPs, permission changes and failed auth.

In this dimension, platform-specific anomaly thresholds is therefore an explicit audit gap.

9. Control test: Third parties

For third parties, inspect bots, tax tools and portfolio apps. Create a key in a non-production or least-privileged context where available, then grant task-specific keys and review vendor access.

In this dimension, vendor internal security is therefore an explicit audit gap.

10. Control test: Decommissioning

For decommissioning, inspect ending access when a job closes. Create a key in a non-production or least-privileged context where available, then delete the key and verify rejection.

In this dimension, residual cached credentials is therefore an explicit audit gap.

Decision scenarios

Scenario 1: when default privilege becomes decisive

Consider a reader whose main constraint is what a newly created key can do. The correct response is not to infer a universal platform or product winner. It is to start read-only and add one permission at a time, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.

Scenario 2: when withdrawal authority becomes decisive

Consider a reader whose main constraint is whether an API can move assets externally. It is to leave withdrawal disabled for analytics and bots, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when ip binding becomes decisive

Consider a reader whose main constraint is network-level restriction of requests. It is to allowlist fixed trusted addresses, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when key type becomes decisive

Consider a reader whose main constraint is HMAC versus asymmetric credentials. It is to prefer supported asymmetric signing for durable systems, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when storage becomes decisive

Consider a reader whose main constraint is where secrets live at rest. It is to use a secret manager rather than code or spreadsheets, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when logging becomes decisive

Consider a reader whose main constraint is risk of leaking headers or signatures. It is to redact secrets and test logs, retain the evidence, and define a stop condition before funds or permissions are committed.