Security Is a Process, Not a Checkbox: Lessons Learned While Hardening Best Guest

What Does Security Mean for a Platform Like Best Guest?

Best Guest is a SaaS platform that helps accommodation providers manage guest registration and related compliance processes in the Czech Republic. The platform handles information connected to accommodation properties, reservations and guests, including data that requires careful handling under data protection and security requirements.

That creates a responsibility that goes beyond simply keeping the application online.

Security has to be considered across the entire system: the application itself, the infrastructure it runs on, the databases it uses, the external services it communicates with and the processes used to develop and operate the platform.

There is no single security feature that solves all of these problems.

Instead, we rely on a combination of security practices designed to reduce unnecessary exposure, limit access, protect data and make potential failures easier to detect and contain.

The following principles have been particularly important during our recent infrastructure reviews.

Security Starts with Asking Better Questions

One of the most useful questions we have learned to ask is:

If we were setting this up today, would we still do it the same way?

Sometimes the answer is yes. Sometimes the answer is no. And sometimes the answer is that the existing solution still works, but there is now a better or more appropriate way to approach it.

Technology changes quickly. Infrastructure evolves. New vulnerabilities are discovered. Security practices that were considered reasonable several years ago may no longer represent the best approach for a modern production environment.

This is why security reviews should not only focus on finding critical vulnerabilities. They should also examine the assumptions behind the system.

During our review, we looked at areas including:

• publicly exposed services and ports;
• database administration tools;
• web server configuration;
• HTTPS and internal communication;
• session management;
• access controls;
• secret storage;
• version disclosure;
• firewall configuration;
• application and infrastructure permissions.

No single item determines whether an application is secure. Security is usually the result of many smaller decisions working together.

A security review is therefore not only an exercise in asking, “Is this vulnerable?”

It is also an opportunity to ask, “Can this be simpler, more restrictive or less exposed than it is today?”

Reducing the Attack Surface

One of the simplest questions we ask about any service is:

Does this actually need to be accessible from the Internet?

Modern SaaS applications often consist of multiple components. Some need to communicate with users, while others communicate with external APIs, databases or internal services. Not all of those components need to be publicly accessible.

In practice, it is surprisingly easy for an internal service to end up listening on a public interface.

There is often a perfectly reasonable explanation. A service may have been exposed during development, a temporary firewall rule may have been added for troubleshooting, or the infrastructure may have changed while an old configuration remained in place.

Over time, the original reason for public access can disappear without the access itself being removed.

This is why reducing the attack surface is one of the most practical security improvements available.

Whenever possible, internal services should only be accessible from the local server, a private network or specifically authorised systems. Public access should be limited to the endpoints that actually need to serve external users or integrations.

The principle is simple: if a service does not need to be publicly reachable, making it unreachable from the public Internet removes an entire category of potential attacks.

This is also a good example of why security does not always require a new product or a more sophisticated technology. Sometimes the most effective improvement is simply removing access that is no longer necessary.

Fewer Public Entry Points Make Infrastructure Easier to Protect

As applications grow, it is common for different services to acquire their own public endpoints. Over time, this can result in an infrastructure where multiple components are individually exposed to the Internet, each with its own configuration, authentication requirements and monitoring needs.

A more controlled approach is to use a central public gateway and route traffic internally to the services that need to handle it.

This architecture provides several practical benefits, including:

• centralised HTTPS management;
• consistent logging;
• simpler firewall configuration;
• easier monitoring;
• fewer publicly exposed ports;
• clearer separation between public and internal services.

It also provides a foundation for future security improvements. Authentication, rate limiting, Web Application Firewall capabilities and additional monitoring can be introduced at a central point rather than implemented independently across every service.

Reducing the number of public entry points does not eliminate risk. It does, however, make the system easier to understand, easier to monitor and easier to protect.

That matters because complexity itself can become a security problem.

The more independently exposed components a system contains, the more configuration needs to be correct.

Defence in Depth: Why One Security Control Is Never Enough

Firewalls are an important part of infrastructure security, but a firewall should not be treated as a complete security strategy.

A firewall controls which network connections are allowed to reach a system. It does not automatically make the application behind an allowed port secure.

A modern application may rely on several layers of protection, including:

• firewall rules;
• reverse proxies;
• application authentication;
• API keys or tokens;
• request validation;
• rate limiting;
• logging;
• monitoring.

Each layer addresses a different type of risk.

This is the principle of defence in depth: rather than relying on a single security mechanism, multiple independent controls are used to reduce the likelihood and impact of a failure.

If one layer is misconfigured or bypassed, another may still limit the damage.

The objective is not to create a system where every individual security control must work perfectly forever. That would be an unrealistic assumption for any sufficiently complex system.

The objective is to avoid a situation where the failure of one control immediately results in the failure of everything else.

Administrative Tools Should Not Be Public by Default

Development and administration tools are designed to make engineers more productive. Database administration interfaces, for example, can make managing a database significantly more convenient than working exclusively from the command line.

The problem is not the existence of these tools.

The problem is unnecessary public access.

An administration interface exposed to the Internet becomes another potential target for automated scanners and attackers. Even if the underlying software is properly maintained, exposing an interface that does not need to be public increases the number of things that need to be protected.

For every administrative tool, we should ask:

• Does this tool need to be accessible at all?
• Who actually needs access to it?
• Can access be restricted by IP address?
• Should it only be available through a VPN?
• Would an SSH tunnel be more appropriate?
• Can the tool be removed entirely from production?

The question is not only whether an interface can be secured.

It is also whether the interface needs to be publicly accessible in the first place.

In many cases, removing unnecessary access is more effective than adding another layer of protection around an interface that should not have been exposed.

HTTPS Should Be the Default

Modern applications communicate constantly. Browsers communicate with servers, servers communicate with external APIs and internal services communicate with one another.

Whenever sensitive information is transmitted, the connection should be protected.

HTTPS encrypts communication in transit and helps prevent data from being intercepted or modified during transmission. For modern web applications and APIs, there is generally little reason for unencrypted HTTP to be the normal method of communication.

If HTTP is enabled, it should typically exist to redirect clients to HTTPS.

This is not a particularly exciting security improvement. Nobody is likely to write a case study about a successful HTTP redirect.

That is probably a good thing.

Many important security improvements are invisible to users. They do not create a new feature in the application, but they make the underlying system safer and more resilient.

Information Disclosure and Security Reconnaissance

Modern software inevitably reveals some information about itself.

HTTP headers, error pages and administration interfaces may expose details such as:

• web server versions;
• PHP versions;
• database versions;
• framework information;
• installed software.

This information does not automatically create a vulnerability. However, it can make reconnaissance easier.

If an attacker can quickly determine which software and versions are running, it becomes easier to compare that information against publicly known vulnerabilities.

Reducing unnecessary information disclosure is therefore a relatively small improvement that can make reconnaissance more difficult.

The goal is not to make the system invisible. A web application needs to communicate with users and other systems, so some information will always be available.

The goal is to avoid revealing more than is necessary.

This is an important distinction because not every security improvement needs to eliminate a vulnerability entirely. Sometimes reducing the amount of useful information available to an attacker is itself a worthwhile improvement.

Secure Defaults Are Not Always Enough for Production

Most software works perfectly well with its default configuration. That is, after all, the purpose of having defaults.

However, default settings generally need to balance usability, compatibility and convenience across a wide range of environments. Production systems often require additional hardening.

Areas worth reviewing may include:

• session lifetime;
• cookie security settings;
• TLS configuration;
• database authentication;
• file permissions;
• logging policies;
• access controls.

A system can be functioning correctly while still having configuration that could be improved.

This is one of the more dangerous phrases in software engineering:

“But everything still works.”

A warning is not necessarily an emergency. However, it should not automatically be ignored either.

Configuration warnings can indicate opportunities to improve reliability, security or maintainability before a small issue becomes a larger operational problem.

The objective is not to change every setting simply because a stricter setting exists.

The objective is to understand what each setting does and decide whether the current configuration is appropriate for the environment.

Protecting Secrets Requires Understanding the Threat Model

Another area we recently revisited was how applications store sensitive configuration.

Database credentials, API keys and other secrets are commonly stored in .env files. This approach is practical and, when handled correctly, is generally preferable to placing credentials directly into source code.

However, it raises a more important question:

What exactly are we trying to protect against?

There are two different security problems:

1. Protecting secrets while they are stored.
2. Protecting secrets while the application is running.

These problems are often confused, but they require different solutions.

Encrypting secrets can help protect against accidental disclosure through:

• source code repositories;
• backups;
• server snapshots;
• deployment mistakes;
• accidentally shared configuration files.

However, the application eventually needs access to those secrets. It needs database credentials to connect to a database and API keys to communicate with external services.

If an attacker has already achieved remote code execution inside the application, the application may be able to access those secrets regardless of whether they were originally stored in encrypted form.

The important distinction is:

Encryption protects stored secrets. It does not protect a compromised application.

This does not make encrypted secrets useless. It means that the security benefit needs to be evaluated against the specific threat being addressed.

For larger infrastructures with multiple developers, automated deployments and compliance requirements, dedicated secret management systems can provide significant benefits.

For smaller, carefully managed environments, strict operating system permissions, limited access and secure deployment practices may provide substantial practical protection without introducing another complex system.

There is no prize for having the most complicated security architecture.

Every additional component also needs to be configured, maintained, monitored and protected.

Sometimes the right security decision is to introduce a new technology.

Sometimes it is to improve the configuration of an existing system.

And sometimes the best decision is not to add another layer of complexity when the additional security benefit would be limited.

Least Privilege Limits the Impact of Mistakes

Security is not only about protecting systems from external attackers. It is also about limiting what happens when something goes wrong internally.

This is where the principle of least privilege becomes important.

Every service, application and user should have only the permissions required to perform its function.

If an application only needs to read from a database, it may not need permission to modify or delete everything in that database. If a service only needs access to one part of an infrastructure, it may not need access to the entire system.

Questions we regularly ask include:

• Does this service really need administrator privileges?
• Can database access be more restricted?
• Are credentials rotated regularly?
• Can access be audited?
• Are backups encrypted?
• Have backups actually been tested?

Least privilege does not prevent every attack.

It limits what can happen after access has been obtained.

That makes it an important part of a broader defence-in-depth strategy.

Security Is an Ongoing Engineering Discipline

Perhaps the biggest lesson we have learned is that security is never finished.

New vulnerabilities are discovered. Software changes. Infrastructure evolves. New technologies introduce new capabilities and, occasionally, new risks.

A system that was configured well last year may still benefit from another review today.

This does not mean that security is impossible.

It means that security is a process.

Every infrastructure review is an opportunity to question previous decisions. Every code review is an opportunity to catch a problem early. Every dependency audit is an opportunity to remove outdated software. Every penetration test is an opportunity to learn something new.

The goal is not to create a system that can never be attacked. No responsible engineer can promise that.

The goal is to continuously reduce unnecessary exposure, limit the impact of failures and improve the system over time.

What This Means for Best Guest

Best Guest helps accommodation providers manage guest registration and related compliance processes in the Czech Republic.

The platform handles information connected to properties, reservations and guests. That means security and responsible data handling are not separate concerns that can be added after the product has been built.

They are part of the engineering decisions involved in building and operating the platform.

This is why we regularly review our infrastructure and development practices.

Not necessarily because something is broken.

Often, the opposite is true.

A system can be working correctly and still have room for improvement. A public service can be unnecessary. A permission can be broader than it needs to be. A default configuration can be made more restrictive. An error response can reveal more information than necessary.

Many of these improvements are invisible to customers.

There is no new button to click and no dashboard feature to demonstrate.

A service may simply no longer be publicly accessible. A permission may be more limited. A deployment process may handle sensitive configuration more carefully.

Most users will never know that these changes have been made.

That is exactly how good security should work.

A significant part of security happens quietly, behind the scenes.

Looking Ahead

As Best Guest continues to grow, our approach to security will continue to evolve.

We will continue to review infrastructure configuration, access controls, dependencies, deployment processes, secret management, monitoring and network architecture.

We will continue to learn from security research, industry practices and our own reviews.

We will also continue to question whether a new security technology actually solves a meaningful problem before introducing it.

Because adding more technology is not automatically the same as adding more security.

Sometimes the right answer is a new tool.

Sometimes it is a better configuration.

Sometimes it is removing something that should never have been publicly accessible in the first place.

Final Thoughts

No company can honestly promise that its software is “100% secure”.

Software is complex. Infrastructure changes. New vulnerabilities are discovered. Humans make mistakes.

What we can do is take security seriously.

We can review our systems, question our assumptions, limit unnecessary access, keep dependencies updated, use multiple layers of defence and learn from what we find.

Security is not a feature that can be added once.

It is not a checkbox on a project plan.

It is an ongoing engineering discipline.

For Best Guest, that means continuously reviewing how we build and operate the platform, improving our infrastructure as the technology landscape changes and treating the information entrusted to us with the level of care it deserves.

The goal is not to claim that security is perfect.

The goal is to make the system safer, more resilient and better understood with every review.