A data breach does not always begin with a firewall failure or a compromised laptop. Sometimes, the issue starts in plain sight: a browser loads code containing access credentials that were never meant to be public.
That is why browser-based marketing integrations and third-party API access deserve much closer attention from growing businesses. Tools for analytics, email marketing, customer journeys, booking flows and personalisation can add speed and convenience, but they can also create a hidden security gap when permissions, tokens and scripts are not tightly controlled.
A recent real-world example helps show the risk. In August 2026, Manchester Airports Group (MAG) confirmed unauthorised access to customer data connected to Manchester, London Stansted and East Midlands airports. The affected information related to car park, lounge, Fast Track and airport Wi-Fi services, with around 8.7 million customers reportedly affected. Email addresses, phone numbers, vehicle registration numbers and postcodes were among the information involved. MAG also said bank and payment card details were not held in the affected system, and that passenger safety and aviation security were not compromised. (The Guardian)
The precise technical route into the data has not been confirmed by MAG. However, the extortion group FulcrumSec has claimed that it used airport-specific Iterable marketing API credentials exposed in client-side JavaScript. Security reporting has examined that claim, including samples that appeared consistent with MAG customer data, but the full method, volume and scope remain allegations rather than confirmed facts. (BleepingComputer; Suriq’s technical analysis)
For growing businesses, the lesson is practical. You do not need to run an airport to face this kind of exposure. If your website connects to marketing platforms, CRM systems, form tools, booking software or automation services, you need to know exactly what your browser-facing code can access and what your third-party APIs are allowed to do.
A brief example: what happened, and what remains unconfirmed?
The confirmed part of the MAG story is serious enough on its own.
MAG disclosed that a cyber incident led to unauthorised access to customer information connected with services across its three airports. The affected data included contact details and booking-related information. MAG said operations continued as normal, with no impact on passenger safety or aviation security.
The reported attack path is less certain.
FulcrumSec claims it found API credentials for the Iterable marketing platform in the airports’ client-side JavaScript. In simple terms, this means the credentials were allegedly included in code sent to visitors’ browsers. Anyone with access to the website could potentially inspect that code using browser developer tools.
The group claims that the keys had permissions broad enough to retrieve customer data from the marketing platform. BleepingComputer reported that samples supplied by the group appeared to match real MAG-related booking information, while also noting that it could not independently verify the complete dataset, the claimed 86GB volume or every detail of the alleged attack method.
That distinction matters. We should not present an attacker’s claim as an established fact. But the alleged scenario is technically plausible and points to a broader lesson for any business using web-based integrations:
Convenience in the browser should never come at the cost of control behind the scenes. If a credential can reach sensitive data, it deserves the same protection as any other critical secret.
Why browser-based marketing integrations need closer security controls
Client-side JavaScript runs in the customer’s browser. It powers forms, analytics, personalisation, advertising tags, chat tools, booking journeys and many other website features.
Because the browser needs to execute that code, anything embedded directly in front-end JavaScript should be treated as public. It may be hidden inside a build process, compressed in a script bundle or loaded through a tag manager, but it is still available to anyone willing to inspect page source, network traffic or browser developer tools.
That does not automatically mean every browser-side integration is insecure. Some tokens are intentionally designed for narrow, low-risk tasks. For example, a token may only record a page view, submit a limited event or identify a public environment without granting access to customer records.
The problem begins when a token, API key or integration account can do more than the browser actually needs. A marketing script may only need permission to send an event, while the underlying credential can also read user profiles, pull booking data or export records in bulk. At that point, convenience has created unnecessary risk.
This is the key point for growing businesses: third-party API security is not just about whether an integration works. It is about whether the integration has the minimum access needed to do its job.
In practice, that means an attacker may not need to:
- break into your server
- bypass multi-factor authentication
- install malware on an employee laptop
- exploit a traditional software vulnerability
They may only need to use a valid credential against a third-party API in a way you never intended.
Why traditional security tools may not spot API misuse
Many businesses rightly invest in endpoint security, firewalls and email protection. These are essential parts of a modern security strategy. However, they do not automatically give full visibility into third-party cloud activity.
If someone uses a valid API key to access a marketing or SaaS platform directly, the traffic may never pass through your office firewall. It may not involve a compromised company laptop. It may not trigger anti-malware tools. From the platform’s perspective, the request can look like normal use of a legitimate integration.
That creates a visibility gap:
- Endpoint security may see no infected device.
- A network firewall may see nothing unusual to block.
- A web application firewall may not inspect the relevant third-party API traffic.
- Patch management may find no missing update or exploited software flaw.
- The SaaS provider’s logs may be the main place where suspicious access appears.
This is why a modern security approach has to include cloud applications, SaaS platforms, API activity, identities and supplier relationships, not just laptops and office networks.
The third-party risk facing growing businesses
Growing companies often connect specialist tools to build a better customer experience:
- a website and content management system
- a CRM platform
- email marketing software
- analytics and advertising tools
- booking, payment or ecommerce services
- customer support software
- forms, automation and reporting platforms
This model is efficient and often necessary. It also means customer and business data may move between systems you do not host or fully control yourself.
The risk is not automatically that a supplier is unsafe. More often, the problem is that nobody has mapped the full relationship between the tools, the data they can access and the permissions each integration has been given.
A marketing team may add a new script. A developer may connect a form to a CRM. An external agency may publish tags through a tag manager. An IT provider may manage hosting but not oversee every SaaS integration. Each choice may make sense on its own, while the bigger picture becomes difficult to track.
For small and growing businesses, this is now a core part of cybersecurity for small business. You do not need a huge enterprise stack to create third-party risk. A relatively simple website can still expose data if browser scripts, APIs and permissions are not reviewed properly.
A practical guide to securing browser-based integrations and API access
1. Classify every integration by data sensitivity
Start by listing every service your website connects to. Include direct integrations and anything loaded through plugins, tag managers or embedded scripts.
For each one, ask:
- What data does it collect, send or receive?
- Does it handle personal data, booking data or customer account information?
- Is the integration browser-based, server-based or both?
- Which team owns it?
- Is it still needed?
This gives you a working map of your exposure. Without that map, it is hard to apply sensible controls.
2. Keep privileged access off the front end
If a key can read, update or export sensitive information, it should not live in browser code.
Instead, the browser should talk to your own back-end service, and your server should make the privileged request using a protected credential. That way, the browser only sees the minimum information required for the user journey.
As a rule, browser-facing tokens should be limited to low-risk functions that are specifically designed for public use.
3. Apply least privilege to every API key and service account
Review each API key, token and integration account with one simple question: what is the minimum access this tool actually needs?
Check whether a credential can:
- read customer data
- export records in bulk
- write or delete information
- access multiple brands, websites or environments
- perform admin actions
- continue working long after the original project has ended
Remove permissions that are not required. Separate development, testing and production credentials. Do not let one token serve every purpose just because it is convenient.
4. Audit what your website really exposes
Checking a private repository is useful, but it is not enough. Build pipelines, plugins, third-party scripts and tag management platforms can all affect the final code that reaches the browser.
Review the live site as a visitor would. Inspect loaded JavaScript files, network requests, public configuration values and third-party calls. This should be part of routine security testing, especially after website changes, agency work or new campaign launches.
5. Rotate exposed or over-permissioned secrets immediately
If a privileged credential appears in client-side code, treat it as exposed whether or not misuse has been confirmed.
Revoke it, replace it and check where the old version may still exist, including:
- source repositories
- build artefacts
- deployment pipelines
- website caches
- content delivery networks
- tag-management systems
- developer devices
- tickets, notes and documentation
Rotation matters, but it is only the start. The safer outcome is to redesign the integration so the browser no longer relies on a privileged secret.
6. Monitor API activity and supplier logs
Enable audit logging wherever your platforms allow it. Then decide what should trigger review.
Useful alerts can include:
- unusual export activity
- large data reads
- access from unfamiliar countries or networks
- new user agents or infrastructure providers
- sudden spikes in API requests
- access outside expected business patterns
- a browser-oriented integration behaving like a bulk data process
If your business depends on a cloud tool, that tool should be part of your monitoring plan. You cannot investigate what you do not log.
7. Put governance around marketing and web changes
Many risky integrations are added during fast-moving campaigns, redesigns or conversion improvements, not through formal IT projects.
That is why businesses need a lightweight approval process for new scripts, pixels, APIs and third-party tools. The goal is not to slow marketing teams down. The goal is to make sure somebody checks data access, permissions, retention, supplier terms and ownership before the integration goes live.
8. Review vendor security and incident response readiness
Before adopting a new marketing or automation platform, understand:
- what information it stores
- how data is transferred
- what logging is available
- how credentials are managed and revoked
- what support is provided during an incident
- whether your contract covers notification and cooperation
- which internal team is responsible for ongoing review
Revisit these questions at least annually and whenever the integration changes significantly.
9. Prepare customer communications before you need them
A third-party data issue is not only a technical event. It quickly becomes a customer trust issue as well.
Your response plan should define who will:
- confirm the facts
- work with legal and data protection advisers
- assess whether regulatory notification is required
- notify affected customers if necessary
- provide practical guidance about phishing and fraud
- handle press, website and social media messaging
Do not speculate about the technical cause before it is verified. In the MAG case, customers were advised to be cautious of unexpected messages claiming to be from the airports and to reject requests for payment, banking information or passwords. That kind of advice remains useful even while an investigation is ongoing.
Key Insights
- Anything embedded in client-side JavaScript should be treated as public.
- The real risk is not the presence of an API key alone, but what that key is allowed to do.
- Marketing, analytics and automation tools can create meaningful security exposure if permissions are too broad.
- Traditional endpoint and firewall controls may not reveal misuse of valid third-party API credentials.
- Growing businesses should review live browser code, not just internal repositories.
- Least privilege, logging and regular credential reviews are essential for third-party integrations.
- Clear customer communication matters just as much as technical response when an incident affects trust.
The MAG incident is still developing, and the alleged API-key route should not be treated as officially confirmed. Even so, it serves as a useful reminder that business risk often sits in the space between departments: marketing, web, IT, hosting and third-party suppliers all influence the same customer data journey.
Good security rarely starts with saying no. More often, it starts with asking better questions about access, ownership and trust before a small shortcut becomes a larger problem.
For a growing business, the goal is not to avoid modern integrations. It is to use them with clear boundaries, appropriate permissions and proper visibility.
Picnic IT helps businesses do exactly that through managed IT support, managed security and secure hosting. We help growing organisations review their websites, suppliers, cloud tools and security controls as one connected environment, so practical growth does not come at the expense of unnecessary risk.
If you would like a clearer view of what your browser-based tools, marketing integrations and third-party APIs are exposing, contact Picnic IT for a practical conversation about securing your setup.
We would also be glad to hear how your business approaches third-party integrations and browser security, because better resilience often starts with better shared questions.