# Request ID Security

Request IDs are temporary tokens that carry fraud assessment data. If attackers steal and reuse them, they can completely bypass your fraud detection.

***

### How Request ID Attacks Work

<figure><img src="https://3773527904-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FaQpbYgAyZEBrDPFZtNaq%2Fuploads%2FZExvfHFW2LXQczjFcK9O%2Fdiagram-export-10-10-2025-17_49_43.svg?alt=media&#x26;token=4e499266-a941-44c7-ab9d-727184061e2e" alt=""><figcaption></figcaption></figure>

**The Problem**: Your server sees a valid request ID with good fraud scores, but it's being used by an attacker.

{% hint style="warning" %}
💡 Want early access to Guardian? We're currently onboarding select partners for our closed beta program. [Request Beta Access →](mailto:piero.bassa@mugshotlabs.co)
{% endhint %}

***

### Essential Security Measures

#### 1. Request ID Expiration

```javascript
// Check if request ID is too old
const eventTime = new Date(event.identification.timestamp);
const ageHours = (Date.now() - eventTime.getTime()) / (1000 * 60 * 60);

if (ageHours > 24) {
  return res.status(400).json({ error: 'Fraud check expired' });
}
```

#### 2. Usage Frequency Tracking

```javascript
// Track how many times request ID has been used
const usageCount = await getRequestIdUsage(requestId);

if (usageCount > 3) {
  return res.status(429).json({ error: 'Request ID overused' });
}
```

#### 3. Action-Specific Limits

**Risk-based expiration times:**

* **Profile updates**: 24 hours (low risk)
* **Account changes**: 6 hours (medium risk)
* **Payments**: 1 hour (high risk)
* **Password changes**: 15 minutes (critical)

{% hint style="danger" %}
**Never cache request IDs for more than 24 hours.** \
\
Request IDs contain time-sensitive fraud assessments that lose accuracy over time. Longer caching periods create security vulnerabilities and reduce fraud detection effectiveness.
{% endhint %}

***

### Real-World Impact

#### Attack Examples

* **E-commerce**: Fraudster uses intercepted request ID to validate stolen credit card purchases
* **Banking**: Attacker replays request ID to authorize unauthorized transfers
* **SaaS**: Bulk account creation using harvested "legitimate" fraud assessments

#### Detection Patterns

Watch for these attack indicators:

* Same request ID used from multiple IP addresses
* High frequency of expired request ID attempts
* Geographic inconsistencies (ID generated in US, used in Russia)
* Burst patterns of request ID usage

***

### Implementation Recommendations

#### Security Levels by Action

| Action Type         | Max Age    | Max Usage | Why                                |
| ------------------- | ---------- | --------- | ---------------------------------- |
| **View Profile**    | 24 hours   | 10 uses   | Low risk, user convenience         |
| **Update Account**  | 6 hours    | 3 uses    | Medium risk, reasonable reuse      |
| **Process Payment** | 1 hour     | 2 uses    | High risk, fresh validation needed |
| **Change Password** | 15 minutes | 1 use     | Critical, single-use only          |

#### Response Strategy

* **Low violations**: Log and monitor patterns
* **Medium violations**: Require fresh fraud check
* **High violations**: Block transaction and alert security team
* **Critical violations**: Consider temporary IP restrictions

***

### Key Takeaways

**Request IDs are security tokens** - treat them like temporary API keys:

* ✅ Set expiration based on action risk level
* ✅ Limit usage frequency to prevent replay attacks
* ✅ Monitor patterns and alert on suspicious activity
* ❌ Don't ignore age or usage validation

**Balance security with user experience** - start strict and adjust based on user feedback and attack patterns.

***

**Questions about implementing request ID security for your risk tolerance?** Our team helps customers find the right balance between protection and user experience.

{% hint style="success" %}
👉 **Stop fraud before it costs you, Get started for free:** [Sign up and get your API keys](https://dashboard.guardianstack.ai)
{% endhint %}