Security

1. What this tab is, and what it is not

It is a reader. The tab pulls the web server's access log for the application and turns each line into a structured entry you can filter and search. It contains one section — Incidents logs.

It is not a control panel. There is nothing here to switch on, no rule to write, no address to block. Seeing an attack here does not stop it.

That division is worth being clear about up front, because the tab's own description mentions managing security settings:

Read here, act there. The value of this tab is that it tells you what to go and block, and gives you the evidence.

2. Fetching

Unlike the Logs tab, this one loads by itself as soon as you open it — there is a view waiting for you rather than an empty state.

Newest first. Entries are shown in reverse order, so the most recent request is at the top. This is the opposite of the Logs tab, and it is the right way round here: when you are checking whether something is happening now, you want the latest request first.

Fetching is a snapshot. Nothing updates on its own — press Refresh to see what has happened since.

If it fails, the message names the log type it was trying to read; in practice the cause is an unreachable server or a missing access log rather than anything about log types.

3. What each entry shows

Every parsed line becomes a card:

Lines that do not match the standard access-log format are shown raw, in grey, rather than being dropped.

Reading the colours

The amber and red bands mean opposite things. A wall of 4xx is usually someone probing for things you don't have — which is noise unless it succeeds. A 5xx is your own application breaking, and belongs in the Logs tab's error log where the reason will be.

4. Filter badges

Five badges, each with a count:

Two behaviours to know:

• Unparsed lines appear only under All. Selecting any specific level hides them, so a malformed or unusual log line can vanish from view. If something you saw disappears when you filter, go back to All.
• The four counts need not add up to All, for the same reason — All counts every line including the ones that could not be parsed.

5. Text search

Filter logs… matches anywhere in the original log line, case-insensitively, and combines with the level badge. ✕ clears it.

Because it searches the raw line, it covers every field at once — IP, path, status, user agent and referer. That makes it the main investigative tool on the page.

What to search for

Signs of scanning — paths you don't have:

Signs of automation — user agents:

Signs of a specific actor: paste an IP address to see everything one source did, which is how you decide whether it is a scanner, a crawler or a real visitor before blocking it.

6. Reading the tab as a security review

A practical order to work in:

1. 1Fetch 1000 lines — anything less is a keyhole.
2. 2Check Errors (5xx) first. These are your application failing. If there are any, the reason is in the Logs tab's error log.
3. 3Check Warnings (4xx) next, and look at the paths. Scattered 404s across random paths are scanning. Repeated 401 or 403 on a login path is a brute-force attempt.
4. 4Search the offending IP to see the full pattern of what it did.
5. 5Check whether anything succeeded. A scanner hitting /.env and getting 404s is noise. A scanner hitting /.env and getting 200 is an incident — that file is being served and its contents are gone. Rotate every credential in it immediately.
6. 6Act elsewhere — block the IP in the server Firewall, or apply rate limiting and bot rules in Cloudflare Protection.

The judgement that matters

Constant probing is normal and mostly harmless. Any server with a public IP is scanned continuously by automated tools; a log full of 404s for WordPress paths on a Laravel application means the internet is doing what it always does. It is not a reason to panic and not usually a reason to act.

What matters is a 2xx where you did not expect one. The status code is the line between "someone tried" and "someone succeeded", and it is the single most useful thing on this page.

7. Limits worth knowing

• This shows only what reached the web server. Requests blocked by the firewall, or absorbed by Cloudflare before reaching your origin, never appear here. An empty log is not proof of no attacks — it can mean your protection is working.
• It is one application's log, not the server's. Another application on the same server has its own.
• There is no alerting. Nothing here notifies you; you only see it when you look.
• There is no history beyond the log file. Rotation eventually removes old entries, and the tail you fetch is bounded by the Lines setting.
• The tab cannot block anything.

8. Common problems

9. How this relates to other places

The natural pairing: Security shows you the address, Firewall stops it.