Opens in a new tab
Join Free
HotelConnect24 Security

Protect Access. Protect Hotel Data. Reduce the Attack Surface.

HotelConnect24 is designed around layered security rather than a single security feature. Public websites, partner authentication, operational applications, APIs and internal services should each have their own appropriate security boundaries and access controls.

Explore Security Controls → Back to Trust Center
Identity & Access Least Privilege Application Security API Security Abuse Protection Incident Response
Layered Security Model Separate Public Traffic from Operational Hotel Access.
Security
HotelConnect24 Security Architecture

Identity, permissions, validation, network boundaries and operational controls work together to reduce unnecessary exposure.

Identity Authorisation Validation Isolation
Dedicated Authentication Operational partner credentials should not be processed through the public marketing website.
Controlled Permissions Authenticated users should access only the properties and functions assigned to their role.
Validated Interfaces Forms, APIs and partner connections should treat external input as untrusted until validated.
Operational Visibility Relevant events and failures should be observable enough to support investigation and response.
✓
Reduce Exposure Before Trying to Defend Everything Equally. Services that do not need direct public access should not be exposed simply because they exist.
Layered
Separate Authentication Keep partner credentials out of public WordPress
Least Privilege Grant only the access required
Validate Inputs Do not trust public or integration traffic automatically
Prepare for Incidents Security includes detection and response
Security Domains

Security Across the Full HotelConnect24 Platform.

Protecting a booking platform requires controls at several layers. Each layer addresses a different part of the attack surface.

Identity & Authentication

Verify who is attempting to enter operational HotelConnect24 systems before a partner session or privileged workflow is created.

Authorisation

Authentication proves identity. Authorisation determines which properties, data and operations that identity is actually permitted to access.

Application Security

Public forms, application requests and business logic should use server-side validation rather than trusting browser-side controls alone.

API & Integration Security

External systems should authenticate and receive only the API permissions required for their approved technical use case.

Infrastructure & Networks

Public-facing, application and internal infrastructure should use appropriate boundaries rather than exposing every platform component.

Monitoring & Response

Security also requires enough operational visibility to investigate abuse, failures and suspicious activity when they occur.

Identity & Access

A Valid Login Should Not Automatically Mean Access to Everything.

HotelConnect24 partner accounts can be associated with operational hotel information. The security model therefore needs to distinguish between identity, authentication and authorisation.

A user can be correctly authenticated while still being unauthorised to access another property, another organisation or a privileged administrative action.

✓
Dedicated partner authentication Operational partner access should remain outside the public WordPress authentication layer.
✓
Account-specific permissions Users should receive only the roles and property access required for their work.
✓
No shared-password assumption Individual authorised identities are preferable to several staff members sharing the same credentials.
✓
Account lifecycle controls Access should be reviewable and removable when a user no longer requires it.
Access Decision Model IDENTITY
01
Identify User Which partner identity is requesting access?
Who
02
Authenticate Can the identity successfully prove access to the account?
Verify
03
Determine Organisation Which hotel or partner organisation is the identity associated with?
Context
04
Check Permission Is the requested property or operation allowed for that identity?
Allow
05
Create Controlled Session Grant only the authorised application scope.
Access
Security Boundaries

Do Not Put the Entire Platform Behind One Public Door.

HotelConnect24 separates the public marketing surface from partner authentication and operational hotel functionality. The same principle applies to internal application and infrastructure components.

Reducing direct exposure helps prevent a problem in one layer from automatically becoming access to unrelated platform components.

✓
Public website boundary Marketing pages and public forms do not need direct access to every operational system.
✓
Authentication boundary Partner credentials are handled through the dedicated identity layer.
✓
Application boundary Operational functionality becomes available only after authentication and authorisation.
✓
Internal-service boundary Infrastructure services should not be publicly reachable unless they genuinely need to be.
Illustrative Security Layers Reduce unnecessary direct exposure
01
Public Web Layer Marketing site, public content and protected public forms.
02
Identity Layer Partner authentication and account identity.
03
Application Layer Authorised hotel and booking workflows.
04
Service Layer Internal platform APIs and supporting services.
05
Data & Infrastructure Databases, storage, networks and underlying infrastructure.
Application Security

Browser Controls Improve UX. Server Controls Make the Security Decision.

Any request originating from a public browser, external application or partner system should be treated as potentially manipulated.

01 Server-Side Validation Validate required fields, formats, allowed values and business rules after the request reaches the server.
02 Input Sanitisation Normalise and sanitise externally supplied data before storing or using it downstream.
03 Request Size Limits Reject unexpectedly large requests where they have no legitimate purpose.
04 Allowed-Value Lists Use explicit permitted values for fields such as roles, property types or controlled operations.
05 CSRF Protection State-changing browser workflows should include protection against forged cross-site requests.
06 Rate Limiting Repeated automated submissions or sensitive requests should be limited where appropriate.
07 Secret Separation Private credentials and integration secrets should remain server-side and outside public frontend code.
08 Error Discipline Error responses should provide enough information to users without unnecessarily revealing internal implementation details.
Public Form Protection

Public Registration Should Never Equal Automatic Platform Access.

Hotel partner registration is intentionally separated from account activation. A public form can create an application, but it should not directly create privileged access to HotelConnect24.

01
Human Verification Public registration can use a challenge mechanism such as Turnstile, with verification performed server-side.
02
Honeypot Detection Invisible fields can help identify simple automated form-filling bots without adding friction for legitimate users.
03
Submission Timing Checks Suspiciously fast automated submissions can be rejected as one signal within a layered anti-abuse approach.
04
Rate Limiting Repeated submissions from the same source can be limited to reduce automated abuse and resource exhaustion.
05
Request Integrity Security tokens and same-origin checks can help protect browser-based registration workflows.
06
Email Verification Submitted business email addresses can be verified before an application progresses to internal review.
07
Manual or Controlled Approval A verified application still does not automatically become an operational partner account.
08
No Public Password Collection The registration page does not need to collect the future HotelConnect24 partner password.
API & Integration Security

Partner Connectivity Needs Its Own Security Boundary.

An integration should not receive broad access simply because two companies have agreed to connect their systems.

Authentication

Identify the Calling System

Approved integrations should authenticate using the technical identity and method configured for that connection.

Authorisation

Limit the Available Scope

An integration should receive only the resources and operations needed for its approved use case.

Validation

Validate Every Request

Authentication does not make submitted values trustworthy. Payloads and business rules still require server-side validation.

Rate Control

Limit Abusive Request Patterns

Appropriate rate controls can reduce misuse, accidental request storms and unnecessary pressure on sensitive resources.

Secrets

Keep Credentials Out of Client Code

Private API credentials and service secrets should not be embedded in public websites, browser JavaScript or public repositories.

Events

Validate Incoming Webhooks

Where supported, event receivers should verify that incoming requests belong to the expected integration rather than trusting arbitrary POST traffic.

Webhooks & API → Developers Technology Partners
Infrastructure Security

Protect the Platform Below the Application Layer.

Application security is only one part of platform protection. Servers, networks, containers, storage and administrative access also need appropriate controls.

Server Hardening

Unnecessary services should be disabled or restricted and administrative access should remain limited to legitimate operational needs.

Network Segmentation

Services with different exposure and risk profiles should use appropriate network boundaries rather than a single unrestricted network surface.

Controlled Public Exposure

Only services that actually need public internet access should be exposed through the relevant public interface.

Backup Strategy

Appropriate data and configuration backups can support recovery after hardware, software or operational failures.

Patch Management

Operating systems, platform components and dependencies should be maintained so known issues can be addressed as part of ongoing operations.

Operational Monitoring

Relevant infrastructure and application signals should support diagnosis of failures, suspicious behaviour and degraded service.

Logging & Monitoring

Useful Security Logs Should Help Answer What Happened.

Logging can help detect patterns, investigate incidents and understand why an operational request failed. But collecting more data than necessary can also create its own privacy and security risks.

The goal is therefore useful operational visibility rather than logging every possible piece of information without purpose.

✓
Authentication events Relevant login and access events can help identify unusual account activity.
✓
Security failures Rejected requests and repeated abuse patterns can help identify automated attacks.
✓
Operational errors Application failures should provide enough context to support technical diagnosis.
✓
Data minimisation Passwords, secrets and unnecessary sensitive information should not be deliberately written into ordinary logs.
Useful Security Signals OBSERVABILITY
01
Failed Authentication Repeated or unusual failed access attempts
Detect
02
Rate-Limit Events Repeated requests exceeding expected use
Abuse
03
Permission Denials Attempts to access unauthorised resources
Access
04
Application Errors Failures that may affect important workflows
Review
05
Service Health Relevant availability and infrastructure signals
Monitor
Incident Response

Security Also Means Knowing What to Do When Something Goes Wrong.

Even well-designed systems can experience vulnerabilities, misuse, configuration mistakes or third-party incidents. Response planning helps turn an unexpected event into a controlled investigation.

01
Detect Identify suspicious activity or a reported security concern.
02
Assess Determine scope, impact and affected systems.
03
Contain Limit further exposure where possible.
04
Recover Restore safe operation and address the underlying issue.
05
Review Understand what happened and improve relevant controls.
Security Reporting

Found a Potential Security Issue?

If you believe you have identified a security weakness affecting HotelConnect24, report it responsibly. Please provide enough technical information for the issue to be understood without accessing, modifying or disclosing data beyond what is necessary to demonstrate the concern.

Contact HotelConnect24 → Trust Center
01 Do not intentionally access data belonging to another user, hotel or partner.
02 Do not disrupt production systems or intentionally degrade service availability.
03 Do not publish sensitive technical details before HotelConnect24 has had an opportunity to investigate.
04 Include the affected page, feature or workflow and a clear description of what you observed.
Practical Scope

Security Controls Reduce Risk. They Do Not Create Absolute Security.

HotelConnect24 should continuously improve its protection as the platform, infrastructure and threat environment evolve.

Important: This page describes the HotelConnect24 security approach and intended security architecture. It is not a penetration-test report, independent audit, security certification or guarantee that vulnerabilities, unauthorised access, malware, data loss, service interruption or other security incidents can never occur. Specific contractual security obligations, where applicable, are governed by the relevant HotelConnect24 agreement and data-processing terms.
Security FAQ

Common Questions About HotelConnect24 Security.

Does HotelConnect24 use the public WordPress website for partner passwords?
The HotelConnect24 architecture separates the public marketing website from operational partner authentication. Partner credentials should be handled by the dedicated authentication environment rather than by WordPress forms on the public website.
Does a successful login give a user access to every hotel?
No. Authentication and authorisation are separate decisions. A valid user identity should only receive access to properties and functions assigned to that account.
How is the Hotel Partner Registration form protected?
The planned registration workflow combines multiple anti-abuse controls, including server-side validation, human-verification checks, honeypot detection, timing controls, rate limiting, request-integrity protection and email verification before an application progresses to review.
Does submitting a registration form create a partner account?
No. A public registration submission creates only a partner application. Email verification and the required review or onboarding steps should take place before operational partner access is created.
How are external integrations secured?
Approved integrations should use dedicated technical authentication, limited permissions, server-side request validation and appropriate controls for the resources and operations included in the integration.
Are HotelConnect24 API secrets placed in website JavaScript?
Private credentials and service secrets should remain on trusted server-side systems and should not be deliberately embedded in publicly accessible browser code or public repositories.
Does HotelConnect24 use rate limiting?
Rate limiting is part of the HotelConnect24 security approach for appropriate public and sensitive workflows. The exact limits can differ according to the endpoint, risk and legitimate usage pattern.
Does HotelConnect24 guarantee that it cannot be hacked?
No responsible internet service can guarantee that a successful attack or vulnerability can never occur. HotelConnect24 focuses on layered controls, limited exposure, monitoring, recovery and ongoing security improvement.
Is HotelConnect24 certified under ISO 27001, SOC 2 or another security standard?
HotelConnect24 should only claim a specific certification or independent assurance report after that certification or report has actually been obtained and remains applicable. This Security page does not make such a claim.
Does HotelConnect24 encrypt internet connections?
Public and authenticated HotelConnect24 web services should use secure HTTPS connections. Security also depends on appropriate configuration, authentication, permissions and protection of the underlying systems.
What should I do if my partner credentials may be compromised?
Stop using the suspected credentials where appropriate and contact HotelConnect24 support promptly so the account and relevant access can be reviewed. Do not send your password in an ordinary support email.
Can I report a security vulnerability?
Yes. Potential security issues can be reported to HotelConnect24 through the official contact channel. Researchers should avoid accessing unrelated data, disrupting production systems or publicly disclosing sensitive details before the issue has been investigated.
Trust Center Data Protection Service Reliability Subprocessors

Security Should Protect the Hotel Without Getting in the Hotel’s Way.

HotelConnect24 is designed around layered access controls, controlled public exposure, validated interfaces and clear separation between marketing, authentication and operational hotel systems.

Explore the Trust Center → Contact HotelConnect24