FortiBlox LogoFortiBlox Docs
NexusSecurity

Protect Your API Keys

Security best practices for FortiBlox Nexus API keys

Protect Your API Keys

Your FortiBlox Nexus API key is like a password - it provides access to your account and should be protected accordingly. This guide covers security best practices to keep your API keys safe and your applications secure.

Never expose your API keys in client-side code, public repositories, or browser applications!

The Problem: Exposed API Keys

When you hardcode API keys or include them in client-side code, attackers can:

  • Steal your monthly credits by making unauthorized requests
  • Access your data and analytics
  • Exhaust your rate limits, disrupting your service
  • Potentially access other resources if the key has broad permissions

Best Practice #1: Use Environment Variables

Never hardcode API keys directly in your source code.

Don't Do This

// ❌ NEVER DO THIS - API key is visible in your code
const connection = new Connection(
  'https://nexus.fortiblox.com/rpc?api-key=fbx_test_1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p'
);
# ❌ NEVER DO THIS - API key is hardcoded
client = Client("https://nexus.fortiblox.com/rpc?api-key=fbx_test_1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p")

Do This Instead

// ✅ CORRECT - Use environment variables
require('dotenv').config();

const connection = new Connection(
  `https://nexus.fortiblox.com/rpc?api-key=${process.env.FORTIBLOX_API_KEY}`,
  'confirmed'
);
# ✅ CORRECT - Use environment variables
import os
from dotenv import load_dotenv

load_dotenv()

client = Client(f"https://nexus.fortiblox.com/rpc?api-key={os.getenv('FORTIBLOX_API_KEY')}")
// ✅ CORRECT - Use environment variables
use std::env;
use dotenv::dotenv;

fn main() {
    dotenv().ok();
    let api_key = env::var("FORTIBLOX_API_KEY")
        .expect("FORTIBLOX_API_KEY not set");

    let url = format!("https://nexus.fortiblox.com/rpc?api-key={}", api_key);
    let client = RpcClient::new(url);
}

Setting Up Environment Variables

Create a .env file in your project root:

# .env
FORTIBLOX_API_KEY=fbx_test_1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p

Important: Add .env to your .gitignore:

# .gitignore
.env
.env.local
.env.*.local

Best Practice #2: Separate Keys Per Environment

Use different API keys for development, staging, and production environments.

// ✅ CORRECT - Environment-specific keys
function getApiKey() {
  switch (process.env.NODE_ENV) {
    case 'production':
      return process.env.FORTIBLOX_API_KEY_PROD;
    case 'staging':
      return process.env.FORTIBLOX_API_KEY_STAGING;
    default:
      return process.env.FORTIBLOX_API_KEY_DEV;
  }
}

const connection = new Connection(
  `https://nexus.fortiblox.com/rpc?api-key=${getApiKey()}`,
  'confirmed'
);

Benefits:

  • Isolate usage and billing per environment
  • Revoke compromised keys without affecting other environments
  • Apply different restrictions per environment
  • Better monitoring and analytics

Best Practice #3: Enable Access Control Restrictions

FortiBlox Nexus provides multiple layers of access control to protect your API keys.

Domain Restrictions

Restrict API key usage to specific domains (for web applications).

  1. Go to Developer PortalAPI Keys
  2. Click on your API key
  3. Scroll to Access Control
  4. Enable Domain Restrictions
  5. Add allowed domains:
    https://myapp.com
    https://*.myapp.com
    https://staging.myapp.com
// With domain restrictions enabled, this key will ONLY work
// when requests originate from allowed domains

// ✅ Allowed - Request from https://myapp.com
fetch('https://nexus.fortiblox.com/rpc?api-key=fbx_...', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ jsonrpc: '2.0', method: 'getHealth', id: 1 })
});

// ❌ Blocked - Request from https://attacker.com
// Returns: 403 Forbidden - Domain not allowed

Note: Domain restrictions only work when the browser sends an Origin or Referer header. For server-to-server calls, use IP restrictions instead.

IP Address Restrictions

Restrict API key usage to specific IP addresses or CIDR ranges (for server applications).

# Allow only requests from this IP
203.0.113.45

Useful for:

  • Single server deployments
  • Home/office development
  • Specific cloud instances
# Allow requests from this IP range
203.0.113.0/24

This allows IPs from 203.0.113.0 to 203.0.113.255.

Useful for:

  • Corporate networks
  • Cloud provider IP ranges (AWS, GCP, Azure)
  • Data center blocks
# Allow multiple specific IPs
203.0.113.45
198.51.100.12
192.0.2.100

Useful for:

  • Multiple server instances
  • Load-balanced deployments
  • Distributed systems

How to set up:

  1. Go to Developer PortalAPI Keys
  2. Click on your API key
  3. Scroll to Access Control
  4. Enable IP Restrictions
  5. Add your IP addresses or CIDR ranges

Finding your IP: Use curl ifconfig.me or visit https://ifconfig.me

Network Restrictions

Restrict which X1 Blockchain networks (mainnet, devnet, testnet) the API key can access.

// API key restricted to devnet only
const connection = new Connection(
  `https://nexus.fortiblox.com/rpc?api-key=${process.env.FORTIBLOX_API_KEY_DEV}&network=devnet`
);

// ✅ This works - devnet is allowed

const mainnetConnection = new Connection(
  `https://nexus.fortiblox.com/rpc?api-key=${process.env.FORTIBLOX_API_KEY_DEV}&network=mainnet`
);

// ❌ This fails - mainnet not allowed
// Returns: 403 Forbidden - Network not allowed

Benefits:

  • Prevent accidental mainnet usage with dev keys
  • Separate billing for different networks
  • Enhanced security through network isolation

Best Practice #4: Never Use API Keys in Browser Apps

Client-side applications expose API keys to anyone who inspects the network traffic.

The Problem

<!-- ❌ EXTREMELY DANGEROUS - API key visible to all users -->
<script>
  const apiKey = 'fbx_1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p';
  fetch(`https://nexus.fortiblox.com/rpc?api-key=${apiKey}`, {
    method: 'POST',
    body: JSON.stringify({ jsonrpc: '2.0', method: 'getHealth', id: 1 })
  });
</script>

Anyone can:

  • Open browser DevTools → Network tab
  • See your API key in the request URL
  • Copy it and use it for their own purposes

The Solution: Use a Backend Proxy

Create a backend proxy that adds the API key server-side:

// ✅ CORRECT - Backend proxy (Node.js/Express)
const express = require('express');
const app = express();

app.post('/api/rpc', async (req, res) => {
  // API key is stored securely on the server
  const apiKey = process.env.FORTIBLOX_API_KEY;

  // Forward request to FortiBlox with API key
  const response = await fetch(
    `https://nexus.fortiblox.com/rpc?api-key=${apiKey}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(req.body)
    }
  );

  const data = await response.json();
  res.json(data);
});

app.listen(3000);
// Frontend - No API key needed!
fetch('/api/rpc', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ jsonrpc: '2.0', method: 'getHealth', id: 1 })
})
.then(res => res.json())
.then(data => console.log(data));

Alternative: FortiBlox RPC Proxy (Coming Soon)

We're developing an open-source RPC proxy tool (similar to Helius's proxy) that you can deploy to Cloudflare Workers, Vercel, or your own infrastructure.

Features:

  • One-click deployment to Cloudflare Workers
  • Automatic request filtering and validation
  • Custom rate limiting
  • Domain whitelisting
  • Zero cold-start latency

View the roadmap →

Best Practice #5: Rotate Keys Regularly

Regular key rotation minimizes the impact of a compromised key.

Recommended rotation schedule:

  • Development keys: Every 90 days
  • Production keys: Every 30 days
  • After employee departure: Immediately
  • After suspected compromise: Immediately

How to Rotate Keys

  1. Generate a new key in the Developer Portal
  2. Update your environment variables with the new key
  3. Deploy the changes to all environments
  4. Verify functionality with the new key
  5. Revoke the old key in the Developer Portal
# Rotation script example
#!/bin/bash

# 1. Generate new key via API (coming soon) or manually in portal
NEW_KEY="fbx_new_key_here"

# 2. Update environment variables
echo "FORTIBLOX_API_KEY=$NEW_KEY" > .env.production

# 3. Deploy changes
git add .env.production
git commit -m "chore: rotate FortiBlox API key"
git push

# 4. Wait for deployment to complete
sleep 60

# 5. Test new key
curl https://nexus.fortiblox.com/rpc?api-key=$NEW_KEY \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"getHealth","id":1}'

# 6. Revoke old key via Developer Portal

Best Practice #6: Monitor API Key Usage

Regularly review your API key usage for suspicious activity.

What to Monitor

  1. Unusual request patterns

    • Sudden spike in requests
    • Requests at odd hours
    • Requests from unexpected geographic locations
  2. Unexpected endpoints

    • Endpoints you're not using in your application
    • High-cost operations you didn't initiate
  3. Error rates

    • Sudden increase in 403 (Forbidden) errors
    • Authentication failures

Set Up Alerts

In the Developer Portal:

  1. Go to SettingsNotifications
  2. Enable alerts for:
    • Rate limit exceeded
    • Unusual usage patterns
    • API key approaching credit limit
    • Failed authentication attempts

Best Practice #7: Use Least Privilege Principle

Only grant the minimum necessary permissions to each API key.

Service-Specific Keys

Create separate keys for different services:

// ✅ CORRECT - Separate keys for different services

// RPC-only key for blockchain queries
const rpcKey = process.env.FORTIBLOX_RPC_KEY;

// Geyser-only key for WebSocket streaming
const geyserKey = process.env.FORTIBLOX_GEYSER_KEY;

// Enhanced API key for NFT/token data
const enhancedKey = process.env.FORTIBLOX_ENHANCED_KEY;

Benefits:

  • Limit blast radius of compromised keys
  • Better cost tracking per service
  • Easier to debug issues
  • Granular access control

Security Checklist

Use this checklist to ensure your API keys are secure:

  • API keys stored in environment variables (not hardcoded)
  • .env files added to .gitignore
  • Separate keys for dev, staging, and production
  • Domain restrictions enabled (for web apps)
  • IP restrictions enabled (for server apps)
  • Network restrictions configured
  • Keys rotated at least every 90 days
  • Usage monitoring and alerts enabled
  • Backend proxy used for browser applications
  • Least privilege principle applied
  • Old/unused keys revoked
  • Team members use their own keys (no sharing)

What to Do If Your Key is Compromised

If you suspect your API key has been compromised:

  1. Revoke the key immediately in the Developer Portal
  2. Generate a new key with a different name
  3. Review recent usage for suspicious activity
  4. Update all applications with the new key
  5. Check your billing for unexpected charges
  6. Contact support at [email protected]

Act quickly! The faster you revoke a compromised key, the less damage an attacker can do.

Additional Resources

Questions?