Ask the Expert: Your Website Works Well… But Is It Actually Secure?

Your website may run fast, its pages may look perfect, and every feature may work exactly as expected, yet it may still contain a vulnerability that lets someone reach data no one should see. So how do you find the weak points before they turn into a real problem?

Imagine you’ve just finished building a website. You’ve tested every page, connected the APIs, and made sure login works without issues. Everything looks perfect. But have you tried logging in as a regular user and then trying to reach another user’s data? And have you tested what happens when the client sends a request the interface doesn’t allow?

This is where the difference shows between a website that works well and a website designed to be secure.

Security isn’t an extra feature added just before launch, nor a task that ends once login is switched on. It is a core part of how a system is designed, built, tested and maintained.

1. The interface isn’t your real line of defence

A common mistake is believing that hiding a button or stopping a user from opening a page is enough to protect the function behind it.

Say you have a dashboard with a button to delete a user, and that button only appears for the administrator (Admin). It looks right from the interface’s point of view, but what if a regular user could send the delete request straight to the server?

If the server carries out the request without checking the permissions of the person who sent it, hiding the button didn’t actually protect the system.

The core rule: for every sensitive action, the server must check that the user is allowed to perform it, whatever restrictions the front end applies.

The interface can improve the user experience and hide options that aren’t available, but it is no substitute for security checks on the server.

2. APIs may expose more than you expect

APIs are a core part of most modern applications: they connect the front end to the server and let you fetch, change and delete data. But having an API doesn’t make it secure automatically.

Imagine an app that lets users view their profile through a path like:

GET /api/users/125

The system may check that the user is logged in, but not whether they are entitled to see the data of the user with ID 125.

If changing the ID gives access to another account’s data, this may be a Broken Object Level Authorization (BOLA) vulnerability.

To limit this kind of problem, make sure the server:

• Verifies the identity of whoever sent the request.
• Checks access rights to the requested resource in every relevant operation.
• Doesn’t rely on client-supplied IDs alone to make authorization decisions.
• Returns only the data the task needs, without exposing internal or sensitive information.
• Applies the same checks to updates and deletes, not only to reading data.

Remember: knowing an API address or holding a resource ID does not mean having permission to access it.

3. Being logged in doesn’t mean having permission

There is a fundamental difference between authentication and authorization:

• Authentication: who are you? The process by which the system verifies the user’s identity.
• Authorization: what are you allowed to do? Deciding which actions and data the user may access.

A user may be properly logged in yet have no permission to delete a record, view an admin report, or change another company’s data.

For example, a business management system might have these roles:

It isn’t enough for the app to store the user’s role in the front end and assume it can’t be changed. The server must rely on a trusted identity and a clear permissions policy, and check the required permission whenever a sensitive operation runs.

It’s also important to apply the Principle of Least Privilege: give each user the minimum permissions they need to do their work, and don’t grant extra ones just because they might be useful later.

4. Passwords and security tokens aren’t minor details

The login mechanism can be a weak point even when the rest of the site is carefully designed. Important practices here:

• Store passwords with algorithms built for password hashing, such as Argon2id or bcrypt, with suitable settings, instead of plain text or a fast hash that isn’t meant for this purpose.
• Use HTTPS to protect data in transit between the browser and the server.
• Put sensible policies on repeated login attempts to limit automated password guessing.
• Manage sessions and access tokens securely, with a defined lifetime and the ability to revoke them when needed.
• Never put server secrets or secret API keys in front-end code or public repositories.
• Protect password-reset and account-verification flows, because they can become a way around authentication.

If the app uses JWT, verify the signature, algorithm, issuer, audience and expiry as the system’s design requires, and don’t treat a token’s contents as trustworthy just because they can be decoded.

5. Not all user data is equal

One mistake that can slip by unnoticed is a server returning every field of a record while the interface needs only a few of them.

Imagine a profile page that needs the name and email, but the response also includes internal data or fields the user shouldn’t see. Even if the interface doesn’t display them, they can still be in the network response and reachable through developer tools.

So it’s better to define the fields allowed in the response for each use case, validate incoming data on the server, and not rely on front-end validation alone.

The same applies to file uploads: check the file’s type, content and size, restrict where it’s stored and who can reach it, and don’t trust the file name or extension alone.

6. Test what the interface doesn’t show

Testing the site from a normal user’s point of view is essential, but it isn’t enough on its own to judge security. Add cases that check how the system handles unexpected requests:

• What happens if a user who isn’t logged in tries to reach a protected path?
• What happens if an employee tries an operation reserved for managers?
• Can a user view a record that belongs to another user?
• Does the server reject invalid data, or fields it doesn’t allow to be changed?
• Do the interface and the server handle errors safely, without revealing sensitive internal details?
• Do private files, reports and resources stay protected when accessed directly?

Tools such as OWASP ZAP or Burp Suite can be used in authorized security testing, alongside automated tests that check authentication, authorization and input validation.

Run these tests only in an environment you own or have clear permission to test.

7. A checklist before you launch

Before publishing any web application, review these essentials:

• Every sensitive operation checks permissions on the server.
• A user can’t reach another user’s data without permission.
• Passwords are stored with secure, suitable hashing.
• Connections are protected with HTTPS.
• Secret API keys and other secrets are not in front-end code.
• Inputs and uploaded files are properly validated.
• Sessions and access tokens are managed securely.
• Error messages don’t reveal unnecessary internal details.
• Libraries and dependencies are updated and checked for known vulnerabilities.
• There is a process for reviewing security logs and responding to incidents.

This list is a starting point, not a guarantee that the application has no vulnerabilities. The level of protection needed depends on the nature of the system, the data it handles, and the risks around it.

The takeaway: security starts with how you think

Every functional test may pass, the interface may run smoothly and the user experience may be excellent, yet the system can still be exposed to security problems if its permissions aren’t carefully designed or its APIs aren’t properly tested.

A professional developer doesn’t only ask, “Does this feature work?” but also: “Who can use it? What data can they reach? And what happens if they try to step off the expected path?”

Because a good website isn’t just one that carries out the right requests; it’s one that also knows how to refuse unauthorized ones.

The question worth asking yourself before launching your project isn’t only “Does my site work as it should?” but: can users do what they’re allowed to, and nothing beyond their permissions?