Securing Your Integrations

Over the years, we've gotten a ton of questions about our own position in the edtech ecosystem. The general consensus on third-party integration platforms (like Edlink) is that they are inherently introducing added security risk because they represent a new attack surface for your institution or company. This is a valid concern and we've taken it seriously.

We set out with a goal to flip this narrative on its head. We asked: "How can we deliver integrations in a way that is more secure than if you were to build them yourself? What can we build that other companies are unable (or at least, unlikely) to build themselves?"

The answer to that question is built-in, real-time, API & SSO security.

The first slice of that work is already in the dashboard as Network Firewall: IP allowlists and blocklists, VPN and Tor controls, and country-level geofencing. You can configure it for district integration traffic, dashboard sign-in, and application API keys.

Detecting Unauthorized API & SSO Requests

Detecting and preventing attacks in real-time is a critical part of securing your integrations (for both institutions and companies). If a teacher or administrator loses control of their primary account (e.g. via a phishing attack) the attacker may be able to gain access to dozens or hundreds of other connected applications. The blast-radius of an attack like this can be devastating and not limited to just the account that was originally compromised.

IP Address Restrictions and Geofencing

These controls are available today on each Network Firewall policy.

• IP Allowlisting: Restrict usage to a specific IP address or a range of IP addresses using CIDR notation (e.g., 192.168.1.0/24). Requests originating outside of these predefined networks can be rejected.
• IP Blocklisting: Deny specific addresses or ranges you already know are unwanted, even if they would otherwise match a known network.
• VPN and Tor: Optionally deny traffic Edlink identifies as coming through a VPN or the Tor network.
• Geofencing: Allow or deny traffic based on the country of the request IP. If your backend servers are exclusively hosted in North America, you can reject traffic that originates elsewhere.

Device and User Agent Fingerprinting

Attackers often use automated scripts, headless browsers, or generic HTTP clients (like cURL or Postman) when testing compromised keys.

• User Agent Validation: Enforce strict User-Agent policies to ensure requests match the expected footprint of your backend architecture or authorized SDKs.
• Cryptographic Fingerprinting: For requests originating from client-side environments or specific server architectures, evaluate underlying characteristics to create a persistent fingerprint. Sudden, illogical shifts in the fingerprint associated with a specific API key would trigger an anomaly alert and block the request.

Behavioral Anomalies and Velocity Controls

Detect and mitigate brute-forcing, token testing, and unusual data exfiltration patterns in real-time.

• Endpoint Velocity Limits: Set granular, dynamic rate limits on sensitive endpoints. If a compromised key suddenly spikes in read requests attempting to scrape data, the system would temporarily throttle the key and immediately alert your security team.
• Impossible Travel Detection: If an API key is used to authenticate a request from a data center in Virginia and then, seconds later, from a proxy server in Eastern Europe, the engine would flag the physically impossible travel scenario and block the anomalous request.

Hardening in Action

Even with only the controls that ship today, the posture shift is visible in a few common scenarios.

1. If an API key is leaked in a public repository, a standard key remains fully vulnerable until an administrator manually revokes it. With unknown-IP blocking, requests fail when the key is used outside your known networks.
2. Proxy and anonymity-network abuse is another common pattern. VPN and Tor controls, plus geofencing, stop a class of traffic that a secret alone cannot identify.
3. A dashboard login from an unexpected country can be denied by the team's dashboard firewall without changing how schools launch SSO into your application.

The remaining items above (fingerprinting, velocity, impossible travel) are how we intend to catch abuse that still originates from an allowed network.

How to Get Started

You do not have to wait on the rest of the roadmap to get value from these controls.

1. Audit existing usage. Identify the static IP addresses and countries that legitimate dashboard, server, and (if applicable) district traffic originates from.
2. Configure Network Firewall in a non-production application first when you can, especially before blocking unknown IPs on a live API key.
3. Add known IPs before enabling allowlist-style blocking, particularly on dashboard access, so you do not lock your own team out.

Network Firewall is available to both companies and school IT administrators. Each policy is scoped: an application's firewall does not replace a district's, and dashboard access is separate from API traffic.