Integration Security Best Practices

An integration is a promise between two systems: I will accept your data and act on it, and you will accept mine. That promise is worth attacking, because on the far side of most integrations sits a database of customers, financial postings, employee records or operational controls. Attackers understand this better than many of the teams building the connections. They have stopped hammering the front door of the monolith and started probing the service accounts, the tokens, the webhooks and the message queues that quietly stitch the estate together. If you want the wider picture of how these connections are designed in the first place, start with the pillar, enterprise system integration explained, and treat this article as the security layer that sits on top of it.

The message up front: integration security is not one control, it is a stack of overlapping controls where each layer assumes the one outside it might fail. Authentication proves who is calling, authorization limits what they can do, encryption protects the data in motion, secrets management keeps the credentials out of reach, validation rejects malformed input, rate limiting blunts abuse, and monitoring tells you when something is wrong. Remove any one and the others have to carry more weight than they were designed for.

1. Why integration is a prime attack surface

A well-run organisation spends years hardening its core applications: patch cycles, access reviews, penetration tests, security awareness training. Then it connects those applications to each other, to partners, and to cloud services, and every one of those connections becomes a path that the original hardening never fully considered. Integrations are attractive to attackers for reasons that are structural, not accidental.

First, integrations cross trust boundaries by definition. The whole point of an integration is to let data leave the zone where one team controls it and enter a zone where a different team, a different vendor or a different network controls it. Every boundary crossing is a place where assumptions can diverge and where an attacker who compromises one side gains a foothold on the other.

Second, integrations run with standing credentials. A user session expires when someone logs out, but a service account or an API key that drives a nightly synchronisation lives for months or years, often with broad permissions, frequently unrotated. A stolen integration credential is a stolen credential that keeps working long after a human password would have been changed.

Third, integrations are under-monitored. Interactive user activity is watched closely, but machine-to-machine traffic is treated as background noise. An attacker who learns to imitate a legitimate integration can move data for a long time before anyone notices, because the traffic looks exactly like the traffic that is supposed to be there.

Fourth, integrations accumulate. Over years an estate grows dozens or hundreds of point-to-point connections, webhooks, file drops and message flows, many built quickly, some by people who have since left, few documented well. The attack surface is not just large, it is poorly inventoried, which means parts of it are effectively unowned. You cannot defend what you have forgotten you built.

2. Authentication and authorization

The first question any integration endpoint must answer is who is calling, and the second is what they are allowed to do. These are two different questions, and conflating them is one of the most common and most damaging mistakes I see. Authentication establishes identity. Authorization establishes permission. A system that authenticates well but authorizes carelessly will happily let a correctly-identified caller do things it should never be able to do.

For modern service-to-service and delegated access, OAuth 2.0 is the standard worth building on. It separates the party that owns the data from the party that wants to act on it, and it issues short-lived access tokens with defined scopes rather than handing over a long-lived password. The client authenticates once, receives a token, and presents that token on each call. When the token expires the damage window from a leak closes on its own. For the mechanics of grant types, tokens and the flows that matter for machine-to-machine work, see OAuth 2.0 explained, and for the wider comparison of key-based, token-based and certificate-based approaches, API authentication methods.

For the highest-assurance connections, particularly partner integrations and internal service meshes carrying sensitive data, mutual TLS raises the bar further. Ordinary TLS proves the server's identity to the client. Mutual TLS also proves the client's identity to the server, using a certificate that the client must present and the server must validate against a trusted authority. The result is that neither side will talk to an unverified counterpart, and a stolen bearer token alone is not enough to impersonate a client that also has to prove possession of a private key. Mutual TLS is more work to operate, because certificates must be issued, distributed and rotated, but for the connections that matter most it is the strongest widely-supported option.

Whatever the mechanism, resist two temptations. Do not accept static API keys embedded in URLs, where they end up in logs, proxies and browser history. And do not treat successful authentication as authorization. A valid token says who; your own logic must still decide what.

3. Encryption in transit and at rest

Data in an integration exists in two states that both need protecting: moving between systems, and sitting in the stores and queues along the way. Encryption in transit and encryption at rest address these two states, and neither substitutes for the other.

In transit, every integration hop should run over TLS, and specifically over a current version of TLS with modern cipher suites. This is non-negotiable for anything crossing a network you do not fully control, and it should be the default even for internal traffic, because the flat trusted internal network is a fiction that attackers exploit routinely once they are inside. Plain HTTP, unencrypted FTP and cleartext database connections have no place in a modern integration, regardless of how private the network feels. Enforce TLS, reject downgrade attempts, and validate certificates properly rather than disabling verification to make a stubborn connection work, which is a shortcut that quietly removes the entire protection.

At rest, the data that integrations stage, queue or cache also needs encryption. Message brokers hold payloads. Integration platforms buffer files. Databases store the synchronised records. Each of these is a place where sensitive data sits still long enough to be stolen in bulk, and each should be encrypted at the storage layer so that a compromise of the underlying disk or backup does not hand over readable data. Encryption at rest is cheap to enable on modern platforms and expensive to have skipped when a backup goes missing.

The layered view: encryption is one ring in a defence that surrounds the integration itself. It protects the data even when an attacker is already past the network perimeter, which is why it belongs alongside authentication and least privilege rather than instead of them. For how these connections are architected end to end, the pillar covers the ground: enterprise system integration explained.

4. Secrets management (no hardcoded credentials)

Every integration runs on secrets: API keys, client secrets, certificates, database passwords, signing keys. How you store and handle those secrets is one of the sharpest dividing lines between a secure integration and a breach waiting to happen, because a leaked secret bypasses every other control at once. An attacker with your integration's credential does not need to defeat your authentication; they are your authentication.

The single most important rule is that credentials must never be hardcoded. Not in source code, not in a config file committed to the repository, not in a container image, not in a script pasted into a scheduler. Hardcoded secrets leak through version control history, through shared images, through code review tools and through the simple fact that once a secret is in a file, it is everywhere that file has ever been copied. A secret that lives in a Git history is compromised even after you delete it from the current version, because the history remembers.

The practice that replaces hardcoding is a dedicated secrets manager: a vault that stores credentials encrypted, releases them to authorised workloads at runtime, controls access with its own policy, and logs every retrieval. The integration asks the vault for the credential when it needs it, uses it, and never persists it. This gives you three things at once: the secret is never in code, access to it is auditable, and rotation becomes a change in one place rather than a hunt across every system that embedded a copy.

Rotation deserves its own emphasis. Long-lived secrets are a standing risk, and the risk grows with every day the secret goes unchanged and every person who has seen it. Rotate credentials on a schedule, rotate immediately when someone with access leaves, and design integrations so that rotation does not require downtime, because a rotation that causes an outage is a rotation that never happens. The goal is a world where a leaked secret is only useful for a short window, because it was going to be replaced soon anyway.

5. Least privilege and scopes

When an integration is granted access, the natural instinct is to grant broadly, because broad access means the integration will not fail for want of a permission and nobody has to revisit it later. That instinct is exactly backwards. Every permission an integration holds is a permission an attacker inherits if they compromise it. The principle of least privilege says grant the minimum access the integration actually needs to do its job, and nothing more.

In practice this means scoping. OAuth scopes let you issue a token that can read one resource but not write it, or access one dataset but not another. A synchronisation that only reads customer records should hold a read-only scope, so that even a fully compromised token cannot modify or delete anything. A webhook receiver that only needs to accept order events should not hold a token that can query the entire order history. The narrower the scope, the smaller the blast radius when something goes wrong.

The same discipline applies to the underlying accounts. An integration user in the target system should have a role built for that integration, granting exactly the objects and operations it uses, rather than reusing an administrator account because it was convenient. Service accounts with administrative rights are a recurring finding in security reviews, and they exist almost always because someone granted broadly to save time during a rushed go-live and never came back to tighten it.

The honest limitation: least privilege is easy to state and tedious to maintain. Permissions granted narrowly at go-live tend to widen over time as new requirements arrive and the fastest fix is to add another grant. Without periodic access reviews, an integration that started least-privileged drifts toward over-privileged one small exception at a time. The control is not the initial grant; it is the recurring review that catches the drift.

6. Input validation and schema enforcement

An integration endpoint accepts data from another system, and the cardinal error is to trust that data because of where it came from. The sending system may be compromised, misconfigured, or simply buggy, and even a legitimate partner can send you malformed or malicious content. Every payload arriving at an integration boundary is untrusted input until your own validation has checked it.

Schema enforcement is the first line. Define what a valid message looks like, its fields, their types, their allowed ranges and formats, and reject anything that does not conform before it reaches your business logic. A strict schema turns a whole class of attacks and accidents into an early, clean rejection rather than a corrupted record or an injection deep inside the system. If a field should be a numeric identifier, a request carrying a string of SQL in that field should fail at the door, not at the database.

Validation goes beyond structure to content and safety. Reject oversized payloads before they exhaust memory. Enforce expected encodings and character sets. Treat any value that will be used in a query, a command, a file path or a downstream request as hostile, and escape or parameterise it accordingly, because injection attacks reach systems through integration payloads just as readily as through user forms. The boundary between two machines is not a safe zone; it is one of the most common places an injection payload enters.

7. Rate limiting and abuse protection

An integration endpoint that answers as fast as it is asked will answer an attacker as fast as it answers a partner. Rate limiting caps how many requests a given caller can make in a given window, and it is one of the simplest controls with the broadest protective effect. It blunts brute-force attempts against authentication, it contains a compromised client that has started making abnormal volumes of calls, and it protects the system behind the integration from being overwhelmed by a flood, whether the flood is malicious or an upstream bug looping out of control.

Effective rate limiting is per-client, not just global, so that one aggressive or compromised caller cannot consume the capacity everyone else depends on. Tie the limit to the authenticated identity, return a clear response when a caller exceeds it, and consider tiered limits that reflect what each integration legitimately needs, because a partner that normally sends fifty messages an hour suddenly sending fifty thousand is a signal worth acting on rather than serving. Rate limiting also buys time: it slows an attack enough that your monitoring has a chance to notice and your team a chance to respond before real damage is done.

8. Logging, monitoring and audit

Every control above can be defeated, and the honest security posture assumes that someday one will be. Logging, monitoring and audit are what turn a silent compromise into a detected one. Without them, an attacker who gets past authentication moves freely and invisibly; with them, abnormal behaviour surfaces while there is still time to act.

Log the security-relevant events: authentication successes and failures, authorization denials, token issuance, rate-limit breaches, validation rejections, and the identity behind each significant action. Logs should record who did what and when in enough detail to reconstruct an incident, and they should be protected from tampering, because the first thing a capable attacker does is try to erase their traces. Send integration logs to a central store the attacker cannot reach from the compromised system, and retain them long enough to investigate a breach that may not be discovered for months.

Monitoring is logging made active. Watching machine-to-machine traffic for anomalies, a sudden change in volume, calls at unusual hours, access to resources an integration never touched before, a spike in authentication failures, catches the compromise that individual controls missed. Because integration traffic is patterned and predictable, it is actually well suited to anomaly detection: legitimate integrations behave consistently, so deviations stand out clearly once you are watching for them. For the practical detail of what to capture and how to make integration observability useful, see integration monitoring and logging.

9. The controls summarized

It helps to see the whole thing at once. Integration security is best pictured as layers wrapped around the connection, each one an independent line of defence so that a failure in any single layer does not expose the data behind it. The diagram below shows the integration at the centre and the controls arranged around it, from the outermost network-facing checks to the innermost protections on the data itself.

The same information laid out as a checklist makes it easier to audit an existing integration against each concern. For every connection you own, you should be able to name the control in force for each row below, and if you cannot, that row is the gap to close first.

No single row on that table is sufficient on its own, and that is the entire point. A perfectly authenticated integration with over-broad scopes leaks data to a compromised but valid client. Flawless encryption around a hardcoded secret protects the wire while leaving the key under the mat. Security here is the product of the layers, not any one of them, which is why an audit that confirms one strong control and stops is worse than useless: it produces confidence without coverage.

10. References

The practices in this guide align with widely recognised industry security guidance rather than any single vendor's product framing. The most directly relevant reference for anyone securing API-based integrations is the OWASP API Security Top 10, the Open Web Application Security Project's consensus list of the most critical API risks, which covers broken authentication, broken object-level and function-level authorization, unrestricted resource consumption, and related failures that map closely to the concerns above. It is maintained by the OWASP community and is the standard starting point for API threat modelling.

Alongside it, the broader OWASP project material on secure design, input validation and secrets handling, together with the transport-layer and cryptography guidance that underpins TLS and encryption-at-rest decisions, forms the reference base for the recommendations here. These are stable, well-known bodies of work; consult the current published versions directly rather than any dated summary, since the specifics evolve as new risks are recognised.

Final thoughts

Integration security fails quietly. There is rarely a dramatic breach at the integration layer that anyone sees coming; there is a service account with too many rights, a secret that sat in a config file, a webhook that trusted its input, and monitoring that watched the users but not the machines. Months later the data is gone and the reconstruction shows that every individual control was almost right. Almost right is the failure mode, because these controls only work as a set.

So the discipline is unglamorous and it is cumulative. Authenticate every caller and authorize each one narrowly. Encrypt the data moving and the data resting. Keep secrets in a vault and rotate them. Grant least privilege and review it before it drifts. Validate every payload as hostile input. Rate limit the endpoints and log the security events somewhere the attacker cannot reach. Do all of it, on every connection, and keep doing it as the estate grows, because the integration you forget to secure is the one an attacker will find. If you are designing or reviewing the connections themselves, the pillar on enterprise system integration explained covers the architecture these controls protect, and the platform-specific view of securing real-world connections is in Business Central APIs and integrations.

Related reading: Enterprise system integration explained, OAuth 2.0 explained, API authentication methods, Integration monitoring and logging, Business Central APIs and integrations.