Deep Dive: Securing Integrations

Integration security is often neglected. Development teams focus on making integrations work — adding security feels like friction. But an unsecured integration is not just a technical risk: it is an attack surface that can expose every system it connects. This deep-dive covers the security risks specific to integration systems and the controls that address them.

Why Integration Security Is a Distinct Problem

Securing an individual application is relatively well understood: validate inputs, authenticate users, authorise operations, encrypt sensitive data. Integration security is harder because:

Integrations cross boundaries. Data moves between systems with different ownership, different security models, and different threat surfaces.
Integration layers hold elevated privileges. An integration service must have credentials for both the source and target system. Compromise the integration service and you have access to both.
Integration channels are attack surfaces. A message queue or API endpoint is a target for injection, replay attacks, and eavesdropping.
Data flows are hard to audit. Tracking exactly what data moved where, and when, requires deliberate design.
Integrations connect to external parties. B2B integrations, partner APIs, and SaaS connectors extend the attack surface beyond the organisation's control.

Authentication Between Systems

Authentication in integration means: how does System A prove its identity to System B?

Option 1: API Keys

A pre-shared secret string included in the request header or query parameter.

HTTP

GET /api/orders HTTP/1.1
X-API-Key: sk_live_abc123xyz

Pros: simple, universally supported
Cons:

Cannot be scoped to specific operations (one key = full access to the API)
Hard to rotate without downtime (must coordinate update across all consumers)
If the key leaks, all access is compromised until rotated
No standard expiry mechanism

When acceptable: low-risk internal integrations, third-party APIs that don't support OAuth.

Option 2: OAuth 2.0 Client Credentials

The industry standard for service-to-service authentication. No user is involved — one service authenticates to another.

Flow:

Integration Service → POST /token (client_id + client_secret) → Auth Server
Integration Service ← access_token (JWT, short-lived)         ← Auth Server
Integration Service → GET /api/orders (Bearer )        → Target API
Target API          validates token against Auth Server's public key

Why it's better than API keys:

Tokens are short-lived (typically 1 hour) — a leaked token expires quickly
Tokens carry scopes — the integration service only gets access to what it needs
Tokens are signed — the recipient can verify they were issued by a trusted authority without calling the auth server
Token rotation is automatic — the integration service gets a new token before expiry

Scopes example:

orders.read           — can read orders
orders.write          — can create/update orders
customers.read        — can read customer data

An integration service that only reads orders should have orders.read scope only. If it is compromised, the attacker cannot write orders.

Option 3: Mutual TLS (mTLS)

Both parties present and validate TLS certificates. The server authenticates the client by verifying its certificate, not just a token.

Client presents certificate ──►   Server presents certificate
                              ◄──
Both verify each other's certificates against a trusted CA

When to use mTLS:

Zero-trust network environments where every service must prove its identity at the transport layer
Financial services regulations that mandate certificate-based authentication
When token-based auth is not available or practical

Operational cost: certificate management (issuance, renewal, rotation) requires automation or it becomes a source of outages when certificates expire.

Option 4: SAML (Security Assertion Markup Language)

XML-based authentication standard used primarily for browser-based Single Sign-On (SSO). Rarely used for service-to-service integration — prefer OAuth 2.0 for machine-to-machine auth.

Authorisation: What Each Integration Is Allowed to Do

Authentication confirms identity. Authorisation controls what that identity is permitted to do.

Principle of Least Privilege

Every integration service account should have only the permissions it needs — nothing more.

| Integration | Permissions needed | What to NOT grant | |-------------|---------------------|-----| | Order sync (reads orders from ERP) | ERP: read orders | ERP: write orders, delete orders | | Customer sync (writes to CRM) | CRM: write customers | CRM: delete customers, access deals | | Analytics feed (reads all) | Source DB: SELECT on analytics views | Source DB: INSERT, UPDATE, DELETE |

Overly permissive service accounts are one of the most common integration security failures. An integration that "needs all permissions to be safe" is a red flag.

Role-Based Access Control (RBAC)

Define roles for integration service accounts:

integration.order-reader — can read orders only
integration.customer-writer — can create and update customers
integration.reporting-reader — can read all reporting tables

Assign service accounts to roles, not directly to permissions. Roles can be reviewed and audited more easily.

Encryption

In Transit

All integration traffic must use TLS. No exceptions for "internal" traffic. An attacker with network access to the internal network can intercept plaintext HTTP or AMQP traffic.

TLS 1.2 minimum; TLS 1.3 preferred
Validate certificates — never disable certificate validation (ssl.verify: false is the most common and most dangerous shortcut)
Use HTTPS for REST APIs, TLS for message broker connections

At Rest

Messages stored in queues, topics, and DLQs contain business data. Encrypt it:

Platform-managed encryption: most cloud brokers (Azure Service Bus, Amazon SQS, Kafka MSK) encrypt at rest by default. Verify this is enabled.

Customer-managed keys (CMK): for highly sensitive data, use your own encryption keys stored in a Key Management Service (Azure Key Vault, AWS KMS). This ensures that even the cloud provider cannot decrypt your data without your key.

Payload-level encryption: for the most sensitive data (PHI, financial), encrypt the message body before publishing. Even the broker cannot read the payload.

Secrets Management

Service account credentials, API keys, TLS certificates, and encryption keys are secrets. They must never be:

Hardcoded in source code
Committed to version control (Git)
Stored in configuration files deployed with the application
Stored in environment variables in plaintext (acceptable only for non-secret config)

Use a Secrets Manager

Store all secrets in a dedicated secrets vault:

| Platform | Secrets Manager | |----------|----------------| | Azure | Azure Key Vault | | AWS | AWS Secrets Manager | | GCP | Google Secret Manager | | Any | HashiCorp Vault |

The integration service fetches secrets at runtime from the vault, using a managed identity (no credentials needed to access the vault itself on Azure/AWS).

Integration Service → authenticate with managed identity → Azure Key Vault
                   ← secret value (API key, connection string)  ←
Integration Service → use secret to connect to target system

Secret Rotation

Secrets must be rotated regularly:

Database passwords: rotate every 30–90 days
API keys: rotate every 90 days or after any suspected compromise
TLS certificates: rotate before expiry (automate with Let's Encrypt or Azure Key Vault auto-rotation)

Automate rotation — manual rotation is error-prone and often skipped.

API Security

Input Validation

Never trust data arriving at an integration endpoint. Validate:

Schema conformance (required fields present, correct types)
Value ranges (quantity > 0, date in valid range)
Business rules (product code exists, customer is active)

Reject invalid inputs at the boundary with a clear error message. Do not pass malformed data through to downstream systems.

Rate Limiting

Without rate limiting, an integration endpoint can be overwhelmed by:

A misconfigured client sending requests in a tight loop
A Denial of Service (DoS) attack

Configure rate limits at the API gateway:

1000 requests per minute per API key
5000 requests per minute per IP

Return 429 Too Many Requests with a Retry-After header when limits are exceeded.

Injection Attacks

If integration data is used in database queries or commands, it must be sanitised:

SQL injection — if order data from an integration is used in a SQL query, use parameterised queries:

JAVA

// UNSAFE
String query = "SELECT * FROM orders WHERE id = '" + orderId + "'";

// SAFE
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM orders WHERE id = ?");
stmt.setString(1, orderId);

Command injection — never use integration data in shell commands or system calls.

XML injection / XXE — when parsing XML from external sources, disable external entity processing:

JAVA

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

Replay Attack Prevention

A replay attack re-sends a previously captured valid message to trigger the operation again. Prevent it:

Use nonces — a one-time token that expires after use
Use timestamps — reject messages with a timestamp older than N minutes
Use idempotency keys — store processed message IDs; reject re-submissions

Compliance and Regulatory Considerations

GDPR

Key integration implications:

Data minimisation: only transmit the fields the target system actually needs. Don't copy full records when one field is required.
Purpose limitation: data must only flow to systems with a legitimate need for it. Document the legal basis for each data flow.
Data subject rights: when a user requests deletion or export, you must be able to trace and act on every system that received their data through integration.
Data transfer: personal data transferred outside the EU must be covered by appropriate safeguards (adequacy decision, Standard Contractual Clauses).
Processing records: maintain a Record of Processing Activities (ROPA) that includes integration flows that handle personal data.

Integration Audit Trail

Every integration that handles personal or sensitive data must maintain an audit trail:

Transaction log entry:
  - What data was transferred (data category, not full payload)
  - Source system and target system
  - Timestamp
  - Initiating service account
  - Volume (number of records)
  - Outcome (success / partial failure / failure)

The audit log must be:

Tamper-resistant (append-only, separate storage)
Retained for the required compliance period
Accessible to compliance and legal teams

Risks Across Integration Types

| Integration Type | Specific Risks | Mitigations | |-----------------|----------------|-------------| | File Transfer | File interception in transit; malformed file causes downstream errors | SFTP or AS2 (encrypted); validate before processing | | Shared Database | Excessive read access; schema changes break consumers | Least-privilege views; controlled change process | | REST API | Token theft; injection; excessive data exposure | Short-lived tokens; input validation; response filtering | | Messaging | Message interception; DLQ data exposure; replay attacks | TLS; DLQ access control; message expiry | | EDA / Event Streaming | Schema drift breaks consumers; sensitive events broadcast widely | Schema registry validation; event filtering; access control | | B2B EDI | Partner credential sharing; man-in-the-middle on legacy FTP | AS2 or SFTP; certificate validation; partner agreement |

Security Checklist for Every Integration

Authentication:

[ ] Is every inbound call authenticated? (OAuth 2.0 or mTLS preferred)
[ ] Is the service account scoped to minimum required permissions?
[ ] Are credentials stored in a secrets manager (not in code or config files)?

Transport:

[ ] Is TLS required for all connections?
[ ] Are certificates validated (not verify: false)?

Data:

[ ] Is sensitive data encrypted at rest?
[ ] Are only the required fields transmitted (data minimisation)?

API:

[ ] Is input validation applied at the integration boundary?
[ ] Is rate limiting configured?
[ ] Are error responses sanitised (no stack traces or internal details in responses)?

Compliance:

[ ] Are all personal data flows documented?
[ ] Is an audit trail generated for sensitive data flows?
[ ] Is data retention configured on queues and logs?

Lecture Summary

Integration services hold credentials for multiple systems — their compromise is higher impact than compromising a single system. Apply extra scrutiny.
OAuth 2.0 client credentials is the standard for service-to-service authentication. Use short-lived scoped tokens, not long-lived API keys.
Apply principle of least privilege to every integration service account — grant only what is actually needed.
All integration traffic must use TLS. Validate certificates. Never disable certificate validation.
Store all secrets (credentials, keys, connection strings) in a secrets manager. Rotate regularly. Never commit secrets to source control.
Validate all inputs at integration boundaries. Apply rate limiting. Prevent injection attacks.
GDPR requires documented data flows, purpose limitation, data minimisation, and the ability to act on data subject rights across all integrated systems.

Next: Technical Lab — Schema Mapping, Transformation & RPA