DEV Community: Harry Agustiana

What a Filesystem Scan Can and Cannot Tell You After a Laravel Intrusion

Harry Agustiana — Thu, 08 Oct 2026 03:49:28 +0000

Most Laravel security tools look at your source code, config, and dependencies before you deploy. That is useful, but it answers one question: is my code safe? After a compromise, you need a different question answered: has anything on this server been added or changed that should not be there?

That is the gap Laravel Scalpel was built for. It is an open-source intrusion evidence scanner that runs inside a Laravel app and inspects the deployed filesystem.

A quick update first. Scalpel is now at v1.11.0 with 66 GitHub stars, and it was recently covered by Laravel News. More important to me, issues and pull requests are now coming from other developers, and the repo has contributors besides me. This post covers how the scanner works and one lesson from the Laravel News test that is worth knowing if you plan to run it in CI.

What it checks

php artisan scalpel:scan runs six scanners by default. Five look at the current files, and one compares them with a saved snapshot.

Structural. Executable PHP files in places PHP should never live, by default public/ and storage/. This covers .php and less common extensions like .phtml and .phar, plus double extensions such as shell.php.jpg.

Obfuscated code. Common backdoor patterns such as eval(base64_decode(...)), compressed payload execution, dynamic function calls, direct evaluation of request input, and long encoded strings.

.htaccess and .user.ini. Handler mappings that let the web server run scripts, external redirects, and PHP directives like auto_prepend_file. That last one is a classic persistence trick, because it runs a hidden file on every request.

Environment. A missing or unreadable .env, a .env under public/, an empty APP_KEY, keys that drift from .env.example, and APP_DEBUG=true in production.

Baseline diff. Record a known-good state, then report added, modified, and deleted files later.

php artisan scalpel:baseline   # record SHA-256, size, and mtime
php artisan scalpel:diff       # compare the current files against it

Create the baseline only when you trust the application state, and turn on HMAC signing before you create the first one. A signed baseline lets scalpel:diff detect a baseline that was regenerated without the signing key.

The limit you should understand first

Scalpel runs in the same process and with the same permissions as your application. If an attacker can change your code, they can also change the scanner or its config. A filesystem scan detects evidence of an intrusion. It is not a firewall and it does not contain anything.

For that reason, run it from an external trigger where possible, keep code directories read-only, and ship results to storage outside the server being scanned.

What an independent test found

The Laravel News review ran Scalpel 1.9.0 on a fresh Laravel app. With a clean state and a baseline, the default scan reported nothing. After adding four harmless fixtures (a fake eval(base64_decode(...)) inside if (false), an avatar.php.jpg, an .htaccess handler mapping, and a .user.ini with auto_prepend_file), the content scanners caught them.

The more interesting result was a false positive pattern. After php artisan optimize compiled the framework views, the next scan reported about 100 MEDIUM and two HIGH findings inside storage/framework/views. The structural scanner allows that directory, but the obfuscated-code scanner still reads the compiled files.

If your app caches views in production, test this before you use Scalpel as a deployment gate. You can add storage/framework/views to content_scan_excluded_paths, but that means skipping content checks for every compiled view. Alternatively, run php artisan optimize:clear and recreate the baseline before scanning.

Using it in CI

Both scalpel:scan and scalpel:diff support table, JSON, GitHub Actions annotation, and SARIF output. --fail-on sets the lowest severity that fails a job.

php artisan scalpel:scan --format=sarif --fail-on=MEDIUM

Exit code 0 means a complete scan with no findings, 1 means findings at or above your threshold, and 2 means findings below it or an incomplete scan, so an unreadable directory never looks like a clean result. A ScanFinished event is also dispatched, so you can send your own Slack, mail, or webhook alert without parsing command output.

Try it

composer require hryagstn/laravel-scalpel
php artisan vendor:publish --tag=scalpel-config

It needs PHP 8.2+ and supports Laravel 10 to 13. If you hit a false positive or a case it misses, please open an issue. Real-world reports like the one above are what make the scanner better.

Source and docs: https://github.com/hryagstn/laravel-scalpel
Command simulator: https://hryagstn.github.io/laravel-scalpel/

I Almost Shipped a Broken Database on Tencent EdgeOne Makers. Here's What Fixed It

Harry Agustiana — Sat, 29 Aug 2026 06:25:27 +0000

Here's a mistake I bet a lot of developers coming from traditional hosting will make on their first serverless edge project: assuming a local database file will just... work.

I made that mistake building OptiQ, a sales-tracking app for small optical shops, on Tencent EdgeOne Makers. This post is less "here's a polished tutorial" and more "here's the debugging path I took," because I think the reasoning matters more than the final answer.

The Project, Briefly

Small optical shops have a messy sales pattern that most POS templates don't handle well. A customer might buy:

Just a frame
Just a lens
A complete pair (frame + lens)
Softlens
Small accessories (cleaning solution, frame screws) — no prescription needed On top of that, the shop needs to track refraction data (OD/OS, cylinder, axis) per customer, and sometimes link it to a sale — but not always. OptiQ is my answer to that: a small, relational, low-cost app built specifically around that flexibility.

Low-cost was non-negotiable here. I'm the only IT person at my company, so I don't get to justify infrastructure spend for a side project — it has to run on free tiers, or it doesn't ship.

Mistake #1: Treating an Edge Function Like a Regular Server

For context, EdgeOne Makers is the rebrand of EdgeOne Pages (as of June 2026) — it grew from "frontend hosting" into a full-stack platform for Web and AI Agent apps, with support for React, Vue, Next.js, Astro, and a few agent frameworks. That expanded scope is what made it worth using for something beyond a static site.

My plan was simple: static frontend on Pages, API logic on Pages Functions, SQLite file for storage. Deploy was smooth — genuinely, push-to-live in minutes, no CDN or SSL setup needed.

Then I hit the wall: edge functions are stateless. There's no persistent filesystem, and a given request might get routed to a different edge instance than the last one. A .db file written on one request could be gone — or inconsistent — by the next. This isn't an EdgeOne-specific limitation; it's true of serverless edge compute generally. But it's an easy thing to forget if your mental model still comes from VPS-style deployments.

Lesson: figure out your state strategy before you write a single API route, not after your first weird bug report.

Mistake #2 (Almost): Picking a Database That Sleeps When You Need It Awake

Once I accepted I needed a managed database, I evaluated three options:

Option 1 — EdgeOne's native KV store. Fast, simple, and built in. But it's key-value only — no joins, no relational queries. For OptiQ, that would mean hand-rolling indexes for every access pattern (transactions by customer, transactions by date range) and computing monthly totals by pulling records into app code and summing manually. It works, but it's the kind of thing that quietly turns into technical debt.

Option 2 — Supabase. Full Postgres, generous free tier, great DX. Then I read the fine print: free projects pause after ~7 days of inactivity and need a manual restore to wake back up. A shop that doesn't sell something every single day could open the app to a database that's asleep. That's a bad failure mode for a business tool, even a small one.

Option 3 — Turso. SQLite (libSQL), but run as a managed service and queried over HTTP — which means it works fine from a stateless edge function, unlike a local file. Real SQL (joins, constraints, aggregates), no idle-pause behavior. This is what I went with, and the schema I'd already sketched needed almost zero changes to work with it.

The Part of the Schema That Actually Matters

Most of OptiQ's schema is unremarkable — customers, products, transactions, transaction line items. The one decision worth calling out:

CREATE TABLE transactions (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  customer_id INTEGER REFERENCES customers(id),
  refraction_id INTEGER REFERENCES refractions(id), -- nullable, on purpose
  total REAL NOT NULL
);

refraction_id is nullable. That's the whole trick. Without it, I'd have needed separate transaction tables (or awkward sentinel values) for "sale with a prescription attached" vs "sale without one" — like buying a bottle of lens cleaner shouldn't require a fake prescription record just to satisfy a NOT NULL constraint. One nullable foreign key instead of a schema fork.

Where EdgeOne Makers' Full-Stack Positioning Actually Paid Off

The thing I didn't expect going in: not having to stitch together three separate vendors. Static hosting, edge API functions, and (once I wired it up) the database connection all lived in one deploy pipeline. If you've ever debugged a CORS or env-var mismatch between a frontend host, a serverless function provider, and a database vendor that don't share tooling, you'll get why that's worth mentioning.

If You're About to Build Something Similar

Decide your state/database approach before your first API route — not as a fix after deploying.
Check what happens to your database on inactivity, not just under load. "Free tier" often hides a failure mode in the fine print.
Use nullable foreign keys deliberately when your domain has "sometimes this relationship exists, sometimes it doesn't" — it's cheaper than modeling every variant as a separate table. OptiQ is live at optiq.logota.biz.id — built on Tencent EdgeOne Makers as part of Codepolitan's DevHandal 2026 Batch 2.

#TencentEdgeOne #EdgeOneMakers #CODEPOLITAN #EdgeOne

How a Broken Laravel App Turned Into Two Open Source Security Tools

Harry Agustiana — Mon, 13 Jul 2026 05:11:32 +0000

I now run a small self-hosted watchtower that pings me on Telegram the moment something looks wrong on any Laravel app I manage. It didn't start as a plan. It started with a friend's text message and a server that had already been compromised for who knows how long.

The app nobody thought was a target

The app was PaketLebaranku.id — a small Laravel + MySQL + Livewire platform running on a modest VPS through Biznet Gio, built for a friend's small business. Its only job: track installment savings for people paying into a Lebaran package program, small recurring deposits that add up to something meaningful once a year.

It's exactly the kind of app that never shows up in anyone's threat model. No enterprise budget, no dedicated ops team, no security monitoring — just a business owner and a friend who built the thing on the side. Which, as it turned out, is precisely why it got hit.

"The app is throwing a 500 error, can you check?"

That was the whole message. I expected a stack trace, maybe a bad migration or an expired dependency. Instead, digging into the error turned up something far worse.

The .env file wasn't misconfigured — it was gone. Any Laravel developer knows what that means: database credentials, app keys, third-party secrets, either already exposed or already pulled by whoever got in.

Then a second find: a handful of backdoor scripts sitting inside public/icons, dressed up to look like they belonged there. Then a third: .htaccess had been rewritten to let Python scripts execute inside a directory that should never be able to run anything.

Three separate footholds, sitting quietly in an app tied to real people's savings, for who knows how long before a user happened to hit an error page.

The gap that actually mattered

Once we'd contained it, the obvious question was "how do I catch this faster next time." But sitting with it longer, I realized the real failure wasn't a missing check — it was that nothing was watching at all. A scan run once, manually, after the fact doesn't help. The incident wasn't caught by a security tool; it was caught by luck, in the form of an annoyed user.

That reframed what I actually needed to build: not just something that could find this class of problem, but something that would look for it without anyone having to remember to ask.

Laravel Scalpel: the checks I wish had already existed

The first piece is Laravel Scalpel, a narrow, fast forensic scanner for Laravel codebases. It doesn't try to be a full SAST suite — it answers the exact three questions that would have shortened this incident from days to minutes: are there files sitting where they shouldn't be, does the environment configuration look right, are there permission or execution paths that shouldn't exist.

It's picked up some traction beyond my own use case — featured by the Laravel Artisan Community, 24+ GitHub stars, and a pull request currently open to get it listed in awesome-laravel.

N8N Bastion: making sure someone's actually watching

The second piece, N8N Bastion, is what closes the real gap. It's a self-monitoring stack built on n8n that turns infrastructure and application problems into a Telegram message — instead of a support ticket that arrives after the damage is done. Laravel Scalpel now runs inside it as a scheduled check, not a tool anyone has to remember to invoke.

Together they cover both halves of the problem: Scalpel knows what to look for on a Laravel app, and Bastion makes sure it's actually looking, on a schedule, without a human in the loop.

Why this is worth open-sourcing

PaketLebaranku.id will never make a breach headline. It's too small, too obscure, too ordinary — and that's exactly the point. There are a lot of small businesses running real, sensitive workloads on a single self-managed VPS with no monitoring at all, not because the owners don't care, but because every security tool out there quietly assumes a team and a budget they don't have.

Laravel Scalpel and N8N Bastion exist because of one real incident on one real app. I'm putting both out there because I'd bet a lot of other small Laravel apps are sitting exactly where PaketLebaranku.id was, right before that 500 error showed up.

If you run a Laravel app on a VPS you manage yourself, I'd genuinely like to know what breaks or what's missing if you try these:

Laravel Scalpel: https://github.com/hryagstn/laravel-scalpel
N8N Bastion: https://github.com/hryagstn/n8n-bastion