Stayntouch IBE : Security, Architecture & Controls

Stayntouch Internet Booking Engine (IBE) is designed using a layered security architecture to protect customers and the platform itself from common web threats.

Security controls focus on preventing automated abuse, reducing vulnerabilities introduced through third-party components, and ensuring that the application behaves in a stable and predictable manner.

These controls are applied at multiple stages, including user interaction, application behavior, and the software development lifecycle.

1. reCAPTCHA Implementation Overview

Stayntouch IBE uses Google reCAPTCHA to protect the application from bots, automated attacks, and abusive traffic, while maintaining a smooth experience for legitimate customers.

The implementation follows a two-step validation model:

• Invisible reCAPTCHA (v3)

  • Operates silently in the background

  • Evaluates user behavior and interaction patterns

  • Assigns a risk score to each request

  • Allows legitimate users to proceed without interruption

• Visible reCAPTCHA (v2) – Conditional Enforcement

  • Automatically enabled when suspicious behavior is detected

  • Triggered if the reCAPTCHA v3 score is below the defined threshold

  • Requires the user to complete an explicit verification step

This two-level approach allows Stayntouch IBE to block malicious traffic effectively while minimizing unnecessary interruptions for genuine customers.

2. Dependency Security Management (Dependabot)

Dependabot is used as part of Stayntouch IBE’s dependency and vulnerability management strategy.

Stayntouch IBE relies on third-party and open-source libraries, which are continuously monitored by Dependabot for known security vulnerabilities. When a vulnerability is identified, Dependabot alerts the development team and provides guidance on required updates.

This process helps ensure that:

• Known security issues are identified early

• Vulnerable dependencies are upgraded in a timely manner

• Exposure to publicly disclosed vulnerabilities (CVEs) is reduced

By actively monitoring dependencies, Stayntouch IBE minimizes risks introduced through external components.

3. Code Quality & Secure Development (Qlty)

Qlty is used within Stayntouch IBE development process to ensure that security and code quality are consistently maintained before any changes are released.

This helps reduce the risk of security incidents caused by coding errors, misconfigurations, or accidental exposure of sensitive information.

As part of the secure development process, Qlty performs automated checks that:

• Enforce coding standards and best practices

• Identify risky or error-prone code patterns early

• Detect accidental inclusion of sensitive information within source code

These checks help prevent issues such as credentials, access tokens, or configuration secrets from being unintentionally introduced into the application.

By identifying and addressing these risks during development, Stayntouch IBE minimizes the likelihood of:

• Unauthorized access due to exposed credentials

• Security weaknesses reaching production environments

• Service disruptions affecting hotel partners or end users

This continuous focus on code quality and secure development provides partners with confidence that changes to Stayntouch IBE are carefully validated and that the platform remains secure, stable, and resilient as it evolves.

4. Cloud Infrastructure & Data Security Controls

Stayntouch  Internet Booking Engine (IBE) is hosted on Amazon Web Services (AWS) and uses native AWS security services to protect application availability, data confidentiality, and system integrity.

These controls add a security layer beyond application-level protections.

‘

Private Virtual Private Cloud (VPC)

Stayntouch  IBE operates within an AWS Virtual Private Cloud (VPC), providing network-level isolation for all application resources.

Only explicitly approved entry points are exposed to the internet; internal services and databases remain private and inaccessible externally.

This network segmentation reduces the attack surface and prevents unauthorized access.

Web Application Firewall (AWS WAF)

Stayntouch IBE is protected by AWS Web Application Firewall (WAF), which monitors and filters incoming traffic before it reaches the application.

AWS WAF defends against common web threats such as SQL injection, cross-site scripting (XSS), and malicious request patterns.

Suspicious traffic can be automatically blocked, adding a proactive security layer at the edge.

Data Encryption in Transit (SSL/TLS)

All data transmitted between users, partners, and Stayntouch  IBE is encrypted using SSL/TLS.

This prevents interception, alteration, or unauthorized reading of sensitive information in transit.

Data Encryption at Rest (AWS KMS)

All data stored by Stayntouch IBE is encrypted at rest using AWS Key Management Service (KMS)–managed encryption keys.

AWS KMS provides secure key storage, rotation, and access control, ensuring data protection at the storage level.

This aligns with industry best practices for protecting sensitive and regulated data.

Secure Secrets Management (AWS Secrets Manager)

Sensitive credentials such as API keys, passwords, and tokens are securely stored using AWS Secrets Manager.

Secrets are never hard-coded or stored in plaintext configuration files.

Access to secrets is tightly controlled using AWS Identity and Access Management (IAM), and usage is auditable, reducing credential exposure or misuse risk.

Summary

By leveraging AWS-native security services such as VPC, WAF, KMS, and Secrets Manager, Stayntouch IBE ensures:

• Strong network isolation

• Protection against common web attacks

• Encryption of data in transit and at rest

• Secure handling of sensitive credentials

These cloud-level controls complement application-level security measures to provide a robust security posture for hotel partners and end users.

FAQ:

Q1. What is the process to add domains for analytics or other integrations (GTM/GA4, Meta, etc.)?

• The booking engine supports analytics and marketing integrations exclusively via Google Tag Manager (GTM)

• GTM is configured through the Sitebuilder admin panel using designated GTM-HEAD and GTM-BODY fields

• The booking engine emits standardized booking and funnel events to GTM

• Third-party tools (GA4, Meta Pixel, etc.) must be configured within the GTM container

• Direct third-party script integration on the booking engine is not supported

Q2. Do you support nonce- or hash-based CSP and do you have a CSP report-uri/report-to endpoint we can use for testing?

• The booking engine does not currently support nonce- or hash-based CSP

• CSP implementation (including reporting endpoints) is on the roadmap for 2026

Q3. If the booking engine is embedded, who controls CSP: the parent site or the booking engine iframe?

• CSP is enforced as per our documentation above

When embedded via iframe: – The parent site controls its own CSP and framing rules – The booking engine iframe controls its own CSP independently

The parent site can allow or block embedding, but cannot control scripts or resources loaded inside the booking engine iframe