Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Knowledge hub / Firewall

Knowledge hub

Firewall

A control deciding which traffic is allowed to reach a system.

What it means

A firewall decides which traffic may reach a system, based on where it came from, where it is going and which port it wants. NIST describes it as controlling the flow of traffic between networks or hosts with different security postures. It is a gatekeeper.

A web application firewall is a different thing with a similar name. It inspects the content of web requests and blocks the ones that look malicious.

Why it matters

The perimeter is all it guards. A firewall cannot see a flaw inside an application somebody is using exactly as designed. When a signed-in customer asks for invoice 1041 instead of 1040, every part of that request is legitimate. A gatekeeper has nothing to object to.

This causes a specific misunderstanding in security reviews. Answering that you have a firewall addresses a question about the network, and people usually offer it in reply to a question about the application. A business that treats them as interchangeable will feel confident about the wrong things. The useful follow-up is short: what would either of them have stopped?

How it shows up

Firewalls earn their place by shrinking what is reachable at all. Databases not exposed to the internet, administrative interfaces limited to known addresses, staging environments closed to the world. That is real work and worth doing, and most teams have some of it left undone.

The gap is everything that arrives through the front door you deliberately left open, where your customers and your application live. Cyberlop does not do network or infrastructure scanning. What we do not do.

Questions people ask

Firewall, answered

Do we still need a firewall if we run entirely in the cloud?

You still need the function, and you probably already have it under another name. Security groups and network rules do the same job.

The question worth asking is not whether one exists. It is which of your services are reachable from the internet, and whether that list matches what you expected.

What is the difference between a firewall and a WAF?

A firewall decides whether a connection may open at all. A WAF reads the content of a web request and decides whether that particular request looks like an attack.

The firewall asks who may knock. The WAF listens to what is being said. Neither knows which customer owns the record being requested.

Will a WAF stop SQL injection for us?

It blocks many common attempts, which buys you time. It is a filter based on what attacks have looked like before, so it can be evaded by someone who works at it.

Treat it as a layer, not as the fix. The fix is parameterised queries in the code.

Our questionnaire answer says we have a firewall. Is that enough?

It answers the network question and leaves the application question open. If the next line asks how you test for broken access control, a firewall is not a response to that.

Buyers increasingly read these answers carefully. Being specific about what each control covers reads far better than a long list.

Does a firewall help against a logged-in user or an insider?

No. Once a request is allowed through, the firewall's job is finished and it has no view of who the user is or what they may see.

What limits that damage is authorisation on every request, least privilege and logging. Those live in your application.

The traffic is allowed. Then what?

A firewall cannot object to a request it was right to let through. We test the application behind it, signed in as each role, and prove every finding. Ask about one application.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.