DEV Community: Oleksii Antoniuk

A Lie Detector for HTTP Requests: Analytics Through Time

Oleksii Antoniuk — Wed, 03 Jun 2026 03:00:00 +0000

Remember that guy from the last article who visited my site using Firefox 140.0 while the rest of the world was still stuck in the 130s? Back then, it felt like an exotic anomaly, a visit from a "guest from the future." But when these "time travelers" start showing up in formation, you realize: it's time to stop being surprised and start classifying them.

(Read the details in the article on my Blog "Through the Looking Glass of Logs: Karachi Police, DuckDuckGo, and IPv6 Magic" )

If the first version of my Laravel analytics package was just a "peep-hole" in the door, version 1.3.0 has evolved into a full-scale digital customs checkpoint—complete with X-rays, biometrics, and an elephant's memory. Let’s look under the hood and break down how to distinguish a real human from a script that desperately wants to be your friend.

Chapter 1: The Evolution of Paranoia (Scoring System)

In the beginning, I was naive. I believed the internet was a world of black and white: if the User-Agent said "Googlebot," it was a robot—we’d shake its hand and show it to the indexing section. If it said "Mozilla/5.0," it was a human—we’d pour them a coffee and log them into the "Visitors" table.

But the reality of 2026 quickly shattered those rose-colored glasses. Today, even the laziest spam-bot, whipped up by a high schooler on a weekend, can mimic the latest Chrome build so skillfully that standard verification methods just give up. The bot no longer screams "I am a robot!". It enters quietly, subtly, rubbing its virtual palms together.

Realizing this, I turned my package into a digital investigator that no longer makes snap judgments. Now, it uses a weighting system (Scoring). The package doesn't issue a verdict immediately—it observes, cross-references facts, and builds a "suspicion file."

Here is what this real-time interrogation protocol looks like:

"Appeared out of nowhere" (+35 points): Imagine someone materializing right in the middle of your kitchen, bypassing the front door. If a request knocks on an internal page (e.g., straight to /checkout or deep into the blog) without a Referer header, my inner detective narrows his eyes. Regular people rarely teleport—they follow links.

"Digital Paleozoic" (+60 points): Suddenly, a guest on Windows XP pops up in the logs. In 2026! It’s like a gentleman in rusty knight’s armor showing up at a high-tech gala. Most likely, we’re looking at an old botnet using ancient libraries for requests. This is a major red flag, almost a conviction.

"Cloud Residency" (+100 points): If an IP check shows the guest lives in an Amazon, Hetzner, or DigitalOcean data center—game over. Normal people don't browse the web while physically sitting in a server rack in Frankfurt. This is an instant bot status, with no right to appeal.

When the total score in this "suspect card" breaks the 70-point threshold, the visit is officially flagged as "non-human."

This approach allows us to stay polite to real people who might just have a weird browser config or a paranoid antivirus stripping referers, while ruthlessly filtering out the "stealth bots" trying to leak into your clean analytics.

Chapter 2: Snitch Ports and the Referer Loop

Sometimes bots mess up on things so absurd that it feels like the script developer decided to wink at me from the shadows. In version 1.3.0, I implemented two traps that have become my favorites in the hunt for automated "guests."

1. Port Leak: The Spy Who Came from the Control Panel

Imagine a customer walking into your store, but their badge says "Junior Hacking Intern at cPanel." You’d be on guard, right? That’s exactly how it looks in the logs.

A real user comes to you from Google, social media, or types the address manually. But vulnerability scanners often work "in tandem" with hijacked hostings or control panels. As a result, a header hits my analytics: Referer: https://some-shadow-site.com:2083 ...

Port :2083 is the classic entry point for cPanel. A real person cannot "accidentally" follow a link from another server's admin panel to your site. It’s a dead giveaway that someone just finished dissecting a neighboring hosting and is now targeting your project. In my config, these "snitch ports" (including Plesk :8443 and Webmin :10000 ) have a weight of 100.

One hit like that, and the bot is instantly sent to the digital ban list before it can even say "Hello World."

2. Referer Loop:** Failing the Turing Test at the Starting Line

Bots try their hardest to look like "one of us." They know that a missing referer is suspicious (we already assigned +35 points for that in Chapter 1), so they try to simulate it. But sometimes they do it with the grace of a bull in a china shop.

I call this the Referer Loop. A bot lands on your page and sets the Referer header to... that exact same page.

Bot Logic: "If I say I came from here, the server will think I just clicked an internal link."

My Analytics Logic: "Buddy, this is your first visit. You haven't been inside yet to navigate from anywhere to anywhere."

Bot Logic: "If I say I came from here, the server will think I just clicked an internal link."

My Analytics Logic: "Buddy, this is your first visit. You haven't been inside yet to navigate from anywhere to anywhere."
If the system sees a page referencing itself during the very first appearance of that IP in a session—the masks are off. Turing test failed, and the bot score gets another 50 points. A living human must first arrive at the site before they can start moving between its pages.

How it looks in code

For those who like to "get their hands on" the implementation, here is the config snippet responsible for this "interrogation" stage:

/** 
* 4. SUSPICIOUS REFERER PORTS 
* Technical ports in the Referer header (cPanel, Plesk, etc.) 
* Real users almost never arrive from these ports. 
*/
'port_leak' => [
    2082, 2083, // cPanel
    2086, 2087, // WHM
    8443, 8880, // Plesk
    2222,       // DirectAdmin
    10000,      // Webmin
],
'weights' => [
    // Traffic arriving from technical control panels
    'port_leak'    => 100,
    // Referer loop detection (URL == Referer on first hit)
    'referer_loop' => 50,
],

Chapter 3: Snowball Effect — The Magic of Retroactive Retribution

If the previous methods were the "border patrol" at the gates, then the Snowball Effect is the work of internal security with access to the archives. This is the most powerful and, I admit, my favorite feature of the 1.3.0 release.

Imagine this: a bot visits you. Not a clunky Python script, but an elite "stealth operative." For the first three pages, it behaves perfectly:

It maintains pauses, mimicking human reading patterns.
It provides flawless headers.
It even "scrolls" (simulates activity).

My system looks at it and says: "Okay, buddy, you look human. Go ahead." We log it as a "clean" visitor, and it ends up in your beautiful statistics. But on the fourth page, the bot slips up.

Professional curiosity takes over, and it wanders into a "honeypot"—trying to read the /.env file or peek into /wp-admin.

In older versions of analytics, we would have simply flagged that fourth visit as "bot activity." But this is absurd! If it tried to steal your access keys at 2:05 PM, it means that at 2:00 PM it wasn't a fan reading your Laravel articles either. It was an enemy lying in wait.

In version 1.3.0, the system switches to Retroactive Retribution mode: "You sneaky piece of hardware!" says the package. "If you're a bot now, you've been a bot all along."

How it works technically: As soon as an IP address hits a critical weight (threshold) or lands in a Honeypot, the package triggers a background task (via Laravel Queue or Command). It pulls up the history of that IP for the last 60 days and "re-colors" all its past, seemingly "clean" visits with bot status.

/** 
* Snowball Effect (Retroactive Cleanup) 
* Automatically flags historical sessions of a newly identified bot. 
*/
'cumulative' => [
    'enabled' => true,
    'history_window_days' => 60, // How far back we are willing to "take revenge"
],

Your statistics are cleaned up retroactively. You open the dashboard and see that the "garbage" hits that managed to slip through disguised as real people have simply vanished. This isn't just analytics; it's a self-cleaning ecosystem.

Chapter 4: UA Detector or "Your Mustache is Falling Off"

To understand how my config works, you need to look at what bots are actually sending in their headers. Here are two classic examples from my logs that are guaranteed to fail the check:

"The Humble Automator"

python-requests/2.31.0 or GuzzleHttp/7

Why it's a bot: No guesswork needed here. These request libraries honestly admit what they are. In the config, they live in the suspicious_ua section:

/**
* 2. SUSPICIOUS USER-AGENTS (Common fragments)
* Common library or tool strings used by scrapers and automated tools.
*/
'suspicious_ua' => [
  'python-requests',
  'guzzlehttp',
  'go-http-client',
  'curl',
  ...
],

"The Forgetful Mimic"

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Why it's a bot: Windows NT 6.1 (Windows 7) and IE 9 in 2026? This is either a very sad computer in a rural library or (more likely in 99% of cases) an old botnet using decade-old presets. This gets penalized via obsolete_os :

/**
* Obsolete OS versions (Windows XP, 2000, etc.) 
*/
'obsolete_os' => [
  'Windows NT 5',
  'Windows NT 6',
  'Mac OS X 10',
],

Code Implementation: Setting the Weights
And here is the heart of the system—the weight matrix in config/visit-analytics.php . This is where we define how strict our "border control" will be.

/* Scoring Weights (Suspicion Matrix) */
'weights' => [
    // Direct entry to internal page without Referer (bot behavior)
    'no_referer'     => 35,
    // Attempting to trick the system by setting Referer to current URL
    'referer_loop'   => 50,
    // If IP belongs to a data center (AWS, Hetzner, etc.) — instant 100% bot
    'datacenter'     => 100,
    // Click speed exceeding human capabilities (< 2 seconds between pages)
    'speed_anomaly'  => 50,
    // Visiting a "honeypot" (e.g., /.env or /wp-admin)
    'honeypot'       => 100,
    // Those weird ports in the referer (cPanel, Plesk)
    'port_leak'      => 100,
],

How the Honeypot Works

This is the most effective and fastest way to purge your logs. We add a list of paths to the config that a normal user of your Laravel app would never visit:

'honeypot_paths' => [
    '/.env',
    '/wp-admin',
    '/.git',
    '/bitrix',
    '/config.php',
    '/phpinfo.php',
],

The moment a script knocks on /.env , it gets is_bot = true and a maximum bot_score . And thanks to the Snowball Effect, all its previous attempts to "act human" on the home page are instantly nullified.

Chapter 5: What’s Next? (Filament Announcement)

Collecting data and filtering it with virtuosity is only half the battle. The real "dopamine hit" comes when you see the results of your work not in raw database tables, but in beautiful, intuitive graphics. There is nothing more satisfying than watching the gray "bot curve" decline while the green graph of real, live humans grows steadily.

Right now, I’m working on bringing all this "looking-glass magic" into the visual plane. In the next major release, I’m planning full integration with Filament. Why dig through configs via the terminal when you can manage your digital security through a stylish UI?

Here’s what’s on the horizon:

Real-time Dashboard: A set of widgets showing your site’s "pulse" in real time. You’ll literally see who the system has "neutralized" just now and for what reason.

Interactive Bot Map: Visualization of attacks and visits.
You’ll be able to see clearly where the Palo Alto scanners are coming from and where the "honest" search engines are lurking. It will look like a cyber-command headquarters.

Admin Panel Weight Management: No more editing .php files just to change a single sensitivity threshold. You’ll be able to fine-tune scoring weights, add new suspicious ports, or update your honeypot list with a few clicks without leaving the comfort of the Filament panel.

But first things first. The path to perfect analytics is a marathon, not a sprint. So stay tuned: I promise the updates will be "tasty," technically elegant, and incredibly useful for those who value the purity of their data.

Epilogue: Purity as a Religion

Ultimately, after implementing behavioral analysis and port checks, my traffic charts have "slimmed down" significantly. Но это та самая диета, которая идет на пользу. Now I know for sure: if I see a visit from Linux via IPv6, it's either my old friend, the "digital detective," or a genuinely interested pro—not just another Palo Alto Networks script that decided to read my Terms of Service.

Logs are not just text. They are a signature. And now, my Laravel package can distinguish the calligraphy of a living person from the mechanical stamps of a typewriter.

Through the Looking Glass of Logs: Karachi Police, DuckDuckGo, and IPv6 Magic

Oleksii Antoniuk — Fri, 29 May 2026 19:33:34 +0000

Remember when I said reality turned out to be harsher? When you open the logs of a custom-built analytics package after a couple of days, you expect to see hits from a few friends and, in the best-case scenario, your mom. Well, maybe a lost translator bot.

Instead, I discovered that the server had become a point of interest for folks who don't just "scroll the feed," but dissect the internet down to its molecules. My little project suddenly transformed into a testing ground for those who prefer silence and IPV6.

Read the first part of the story about how it all began in the article:
How I Built My Own Laravel Analytics Package (and Almost Didn't Crash Production).

In this series, we’ll step "through the looking glass": we’ll find out who Palo Alto Networks are, why bots read my Terms of Service in 7 seconds, and why Linux + DuckDuckGo is now the official mark of quality for a visitor.

1. Chapter 1: Ghost in the Shell (Linux) and the Guest from the Future

The first one to make my freshly-baked analytics package "rustle" like a pro was a guest whose profile looked like a canonical portrait of a cyber-detective. Imagine: Sunday, late evening. Most people are scrolling social media feeds on iPhones. But in my logs, a character pops up entering via IPv6, using Linux, and introducing themselves as Firefox 140.0.

For a second, I froze. It’s April 2026; stable browser versions have barely crawled into the 130s. Who is this? A time traveler? A Mozilla nightly build tester? Or simply someone who knows a little more than "everything" about anonymity and header spoofing? In the world of info-sec, this is a clear signal: we are looking at a "power user" who consciously uses a non-standard stack to avoid blending into the crowd.

He came from the "Looking Glass" — via DuckDuckGo. Its users hate being tracked and know how to look where others are forbidden to enter. And this guest didn't come to my audit just to "click buttons." He behaved like a professional inspector:

First — Politeness. Checked robots.txt. Knocked before entering.
Jurisdictional Study. In a matter of seconds, he "swallowed" the Terms of Service page. Pros always check whose territory they are on before pulling the trigger.
Target Action. He wasn't interested in articles about choosing a framework. He came for a specific tool — a deep DNS audit.

This visit is the highest form of recognition. When a person using software from the future (Firefox 140!) and hiding behind IPv6 tunnels chooses your tool for work — it means you’ve made something truly worthwhile. But it also means your server must be ready to receive such "ghosts." If your security is leaky, such a pro will see it before the first pixel of the interface even renders.

2. Chapter 2: DNS Detective. The "Karachi Police" Case

While my analytics package imperturbably digested traffic, the "Linux user" from the Netherlands decided that enough was enough with the studying of terms — it was time to move on to "field tests." And as his target, he chose not some local spare parts shop, but the domain karachipolice.gov.pk.

When the official website of the police of Pakistan’s largest city pops up in the Sunday audit logs, you involuntarily adjust your imaginary detective hat. What was it? Subtle trolling, a real investigation, or did someone on the other side of the ocean just decide to test their professional aptitude via an independent tool?

Either way, the "Run Audit" button was pressed. And Oleant laid out evidence on the table that would make any sysadmin in Karachi's eye twitch:

DMARC: null

This was the first and biggest "red flag." DMARC is, essentially, passport control for your mail. If it equals null, it means the domain has no policy protecting against email spoofing. Any freshman hacker could send an email with the subject "Urgent Fine" on behalf of the Chief of Police.

SPF with a "soft" character

The ~all policy in an SPF record is like a lock that is closed, but if you pull hard enough, it opens. We’re telling the world which servers have the right to send mail, but then immediately adding: "But if it comes from someone else, accept it anyway, just mark it as suspicious."

IPv6 Facade and Hosted Email

The Karachi Police website honestly resolves via modern AAAA records (hello, IPv6 future!), but their entire email infrastructure hangs on standard servers of a popular low-cost host. It’s like putting an old carburetors from a vintage Lada into a modern supercar.

Observing this audit through the prism of my analytics package, I realized one important thing: there are no borders on the web. A person sitting under the protection of a European provider via an IPv6 tunnel exposes critical security gaps in an Asian government agency in seconds, using a tool written in free time by a web developer for web developers somewhere in Europe.

This is the "Looking Glass," where security isn't the thickness of the walls, but the correctness of a single line in a DNS record. If your domain hasn't been audited in a while, don't hesitate to visit Oleant and run a free DNS audit.

3. Chapter 3: Dancing with Shadows

If in the first chapter we met a live pro, in the third, the "corporate ghosts" enter the game. When you launch a project, you feel like it's just you and a blank sheet of code. But as soon as you record the first hits from Palo Alto Networks bots, you realize: the project is already being watched.

Don't be scared; they haven't hacked my logs. In the world of "heavy duty" security, everything works more elegantly. Palo Alto and their peers build global threat maps by analyzing traffic worldwide. How do they "see" this?

Step 01 | Network Footprint: When my server queries DNS records or ports of a domain, for external monitoring systems, my domain suddenly starts behaving like an active scanner.
Step 02 | Reputation Scoring: If your domain regularly "communicates" with government or corporate nodes in audit mode, Palo Alto's algorithms flag it as a technical analysis node.
Step 03 | Verdict: The domain is assigned a category. Being in "InfoSec" is much more prestigious and safer for reach than hanging in "Uncategorized" or "Suspicious."

Why is this important for us? Because in 2026, domain reputation is your passport to the "clean internet." If your project behaves professionally, uses a fresh stack (Laravel 12!), and is correctly configured, even giants like Palo Alto begin to treat your traffic as a legitimate research tool.

Epilogue

Security isn't scary. It's hygiene. It's the ability to understand who is knocking on your door and why. My analytics package showed me this clearly: from live Linux enthusiasts to the soulless but damn smart machines of Palo Alto.

Logs don't lie. They tell stories cooler than any spy novel. The main thing is knowing how to read them.

And in the next episode...
We’ll break down how one forgotten comma in a Content Security Policy (CSP) can turn your modern project into a pumpkin for Googlebot and why "Mixed Content" is a death sentence for your SEO.

You can read the article about auditing security headers here: Your Digital Fortress: Why a Security Headers Audit is Essential.

TAKE CARE OF YOUR HTTP HEADERS.
SEE YOU THROUGH THE LOOKING GLASS.

How I Built My Own Laravel Analytics Package (and Almost Didn't Crash Production)

Oleksii Antoniuk — Thu, 21 May 2026 21:56:48 +0000

Why Not Google Analytics? (Or why I love reinventing the wheel)

To be honest, this wasn't an easy call. I’ve been in development for quite a while and had grown accustomed to GA. What could be simpler: you slap a script with your ID onto the site, and data starts flowing into the analytics console. All that's left is to wait for the traffic to roll in and then analyze it by country, gender, age groups, and so on.

Yes, that’s how it used to be, but in today’s reality, there are objective reasons to rethink this concept. Let’s be real: hooking up Google Analytics in 2026 is like putting a massive deadbolt on your front door but leaving the keys with your neighbor. Everything seems under control, but the neighbor knows exactly when you came home, what you bought, and why you have a long face. And when someone visits you and wants to stay incognito, the neighbor won't give them the keys, and they won't even tell you they stopped by. Their response would be something like: “Nobody came, I never sleep, everything is under control…”. What am I getting at?

Remember the General Data Protection Regulation (GDPR)?

Now, for your analytics to work, you must display a cookie consent banner and get the user's permission. And that’s where the problem lies. 90% of users don’t accept all cookies—only the strictly necessary ones. And what does that mean? Google Analytics ends up dead in the water. Besides, everyone is sick and tired of these banners. So, if there’s a legal way to ditch them, why not take it?

(To learn how to avoid legal trouble with data protection laws, check out the article GDPR Without the Headache: A Guide for Web Developers in Germany )

The decision to drop GA was made. When I decided to hit the "Eject" button and catapult myself out of the Google ecosystem, I faced a logical question: what would fill the void? Because I still needed the numbers. I started looking at the heavy artillery.

The first candidate was Matomo (formerly Piwik): Probably the most powerful all-in-one machine. It’s like keeping a pet elephant in your backyard. It does everything, the database grows like crazy, but it requires a separate PHP server, MySQL, and constant babysitting. For my small pet projects, it felt like trying to drive nails with a microscope.

The second tool I looked at was Plausible / Fathom: Sleek, modern, and privacy-respecting. But there’s a catch: you either pay a subscription (a questionable investment for a free tool) or you mess around with self-hosted Docker versions, which also eat up a good chunk of your VPS RAM.

I looked at all of this and thought: “Do I really need to spin up an entire infrastructure just to know that 50 people read my article on German taxes yesterday?”. That’s when it hit me: I don’t need a "combine harvester." I need a tiny, precision scalpel that lives right inside my Laravel application.

I wanted something of my own: lightweight, like a morning espresso, and not asking annoying questions about GDPR. Plus, I was simply curious about who all these people (and bots) were "knocking" on my security tools at oleant.net. Since this blog also needed the same tool, I decided to develop a standalone package that could be easily installed via composer and published openly on Packagist.

For those interested in diving into the code, the package is called oleant/laravel-visit-analytics, compatible with Laravel versions 10/11/12. GitHub link: https://github.com/Oleant-NET/laravel-visit-analytics

The Heart of the System: Middleware and the Magic of the Aftertaste

Which architecture to use? There are various ways to implement this. Fortunately, Laravel has a great Middleware mechanism. I decided to stick with that, but would it slow down the user? They shouldn't have to care about my overhead. And what if the database goes down or something goes wrong? A 500 error page as the face of the site is definitely not what I was aiming for.

That’s why a crucial decision was made — to use the terminate() method. In a Laravel Middleware, it’s like a polite waiter: he brings you the check and smiles (the handle() method), and only after you’ve already left the restaurant does he go back to wipe the table and log the tip (the terminate() method).

The user has already received their page and is happy, while our server quietly and without rush writes the logs to the database in that moment. Even if something goes wrong, the client still leaves satisfied, and the waiter... just doesn't get a tip this time. Just kidding, but here’s how it works in practice:

PHP

public function terminate(Request $request, Response $response): void
{
    try {
        // Logic to exclude non-target clients, like Admin etc.
        // …
        // Next, write our visitors to the database
        $this->logVisit($request);
    } catch (\Throwable $e) {
        // If the DB takes a nap, we won't wake the user with a 500 error
        \Log::error("Analytics failed, but we're keeping our cool: " . $e->getMessage());
    }
}

Lifehack: All analytics code must be wrapped in a try-catch. Believe me, there's nothing sillier than "crashing" an entire project just because the logger didn't have enough room for a long User-Agent or some other non-obvious case.

GDPR on the Fly: How Not to Become Public Enemy No. 1
To avoid slapping a banner the size of half the screen saying “We are watching you, bro,” I implemented IP anonymization. We simply trim the last part of the address before it ever touches the database. This anonymizes the user and fully complies with the law. Yet, we can still tell which country, data center, etc., the visit came from. We’ll talk more about data center bots once there's more data to show.

Back to IP anonymization:

PHP

// Before: 192.168.1.154 -> After: 192.168.1.0

It’s like seeing a crowd in masks: you understand that 5 people showed up, but who among them is your neighbor — you have no clue. The law is satisfied, and so is my conscience.

Payload: Gathering Only the Goodies
Initially, I wanted to write everything that comes in the URL to the database. But then I looked at the Livewire logs, where half the state of the planet is passed in the parameters, and realized — the database would explode. So, I decided to implement filtering based on allowed parameters in the config using array_intersect_key. Now, only what I’ve personally authorized in the config ends up in the logs. Clean, orderly, and zero fluff.

The default set in the package config looks like this:

PHP

'whitelist' => [
    'utm_source',
    'utm_medium',
    'utm_campaign',
    'utm_term',
    'utm_content',
    'ref',
],

But you can, of course, change it by publishing the config in your project first:

Bash

php artisan vendor:publish --tag="visit-analytics-config"

After that, a visit-analytics.php file will appear in your config folder. There, you can not only expand the list of tracked parameters (for example, adding something like page or search) but also specify excluded paths so you don't turn your database into a dump for admin panel or technical endpoint logs.

What's Next?

The package started humming, and the data began to flow. I closed my laptop and went to bed, thinking I’d wake up to some visitor charts from a couple of friends. But reality turned out to be much tougher (and more interesting).

In the next episode, we’ll step through the "looking glass": who are Palo Alto Networks, why do bots read my Terms of Service in 7 seconds, and why Linux + DuckDuckGo is a badge of quality for a visitor?

Why I don’t trust my own deployments (and why you should audit your Security Headers)

Oleksii Antoniuk — Sat, 11 Apr 2026 07:15:18 +0000

As a Laravel developer, I’ve always felt pretty safe. Modern frameworks do a lot of heavy lifting, but here’s the cold truth: even the most secure backend can be undermined by a "leaky" frontend or a misconfigured Nginx.

I caught myself constantly jumping between third-party tools every time I deployed a new feature just to make sure I hadn't messed up my Strict-Transport-Security or broken my Content-Security-Policy. Eventually, I got tired of the routine and built my own module within Oleant.

What’s the deal?
I’m talking about the Security Headers Audit. It’s not just another tool that says "everything is bad"; it breaks down exactly what's happening under the hood of your URL.

Why it matters (The Tech Side):
A lot of devs think SSL/TLS is the finish line. But without the right headers, you're still vulnerable to:

Clickjacking (lack of X-Frame-Options).

MIME-sniffing (no X-Content-Type-Options).

XSS attacks that a solid CSP could have neutralized instantly.

My Implementation:
I built this using Laravel 11 + Inertia.js + Vue 3. This stack allowed me to make the audit process incredibly snappy. You drop the URL, and the Vue component reactively renders the status of every critical header.

Give it a spin:
I’ve exposed this tool as a dedicated route here:
👉 https://oleant.net/security-tools/headers-audit

It’s not a bloated "all-in-one" suite — it’s a precision scalpel. If you’re deploying something today, just throw your link in there and see how much "red" pops up. I actually found a few embarrassing gaps in my own older projects this way.

Follow my journey: https://oleant.dev/en/blog

Stop guessing, start auditing: Why I built a custom Web Performance tool for Laravel devs

Oleksii Antoniuk — Tue, 07 Apr 2026 06:57:31 +0000

Hi DEV community! 👋

As a Senior Laravel Developer, I've always been obsessed with one thing: Performance. We all use Lighthouse and PageSpeed Insights, but I felt something was missing—a tool that speaks the language of developers and gives actionable SEO insights without the fluff.

That's why I started building oleant.net.

What’s the goal?

My mission is to simplify Core Web Vitals optimization. It's not just about the score; it's about the user experience and how search engines perceive your architecture.

What I'm sharing here:

On this profile and my technical blog at oleant.dev, I’ll be deep-diving into:

Advanced Laravel optimization techniques.
Real-world Core Web Vitals case studies.
Building high-performance SEO tools from scratch.

I'd love to hear your thoughts! What's your biggest struggle when it comes to web performance?

Check out the auditor here: oleant.net 🚀