DEV Community: Oleksandr Bystrikov

Web application firewall on Netlify for free

Oleksandr Bystrikov — Fri, 28 Mar 2025 08:19:15 +0000

Talented folks built Netlify to reduce development friction. They offer a generous free tier, which is super helpful for the open-source ecosystem. But Netlify needs resources to grow and stay healthy. They offer paid plans and have also hired a special force called sales.

Sales operate strategically. They target areas rich in special kind of prey called enterprise. Like experienced hunters, they conserve energy and wait at the watering hole called security.

The internet is a wild place. And I’ve said it before — please bear with me. I like to explore the mechanics of Newtonian action and reaction in daily life.

Openness and freedom create incredible opportunities for growth. And with great value comes opportunistic behavior. I personally see it as a balancing act and enjoy observing the laws of physics in many forms.

Startup perspective

Last year, I moved all my web apps from an AWS self-managed Kubernetes cluster to Netlify. Since then, I’ve saved 800€ on infrastructure bills and eliminated some complexity. In the process, I did something unusual: I tried an upsell product — GDPR-friendly site analytics for $9/month.

Privacy-friendly observability is a fair deal for me. It offers insights without compromising on core values. I was surprised and genuinely puzzled by the results.

It turned out that Valisa attracted thousands of daily visitors. Most came from Singapore and the US. That was strange because my service focused on European flights. It sparked my curiosity to dig deeper.

I inspected the logs and noticed distinct visitor groups: aggressive crawlers, credential harvesters, vulnerability scanners, reasonable crawlers, and legitimate users. Bad bots, good bots, and humans. My initial reaction was to wait and see.

Bad bots

A few weeks in, I received an alert from Netlify. It warned me that more than half of my server functions quota (125k per month) had been used. Frankly, I like the reality in which resources are limited.

In my experience, the most annoying are credential harvesters and vulnerability scanners. They fire 20-30 concurrent requests per second for around five minutes. I guess we can call it a baby DDoS.

Reckless bots are the mosquitoes of the net. They get particularly active around holidays. 5k requests per day is a common occurrence, and their favorite food is WordPress.

[{
  message: "Blocked request 🚫",
  url: "https://valisa.io/.git/config",
  ua: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0",
  location: "Amsterdam, The Netherlands",
  ip: "45.148.10.80"
},
{
  message: "Blocked request 🚫",
  url: "https://valisa.io/wp-content/uploads/gravity_forms/g/f/f/b/",
  ua: "",
  location: "Dublin, Ireland",
  ip: "52.169.211.111"
},
{
  message: "Blocked request 🚫",
  url: "https://valisa.io//wp-includes/wlwmanifest.xml",
  ua: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
  location: "Boardman, United States",
  ip: "52.34.1.203"
},
{
  message: "Blocked request 🚫",
  url: "https://valisa.io/configs.php",
  ua: "",
  location: "Washington, United States",
  ip: "52.146.39.115"
}]

These requests invoke server functions. Naturally, I went to check Netlify's offer for security and was disappointed to see a "Contact Sales" button.

It was like me coming to the watering hole. I see hunters; they see me. We both shrug because they are after the wild beast. And nothing happens; we continue with our daily business.

Build WAF

Savanna rewards creativity. I hope this post will help founders like me build their products with fewer distractions. However, this solution is not for every scale.

Netlify edge functions offer great power and flexibility. I am fascinated by how tools multiply human potential. Let's build a layered defense for the Astro website.

I started by filtering out traffic targeting WordPress and PHP. Then, I focused on requests without user-agent header and those containing specific keywords like .git or .env. These rules deny access to many unwanted visitors.

It took me some time to refine them by observing usage patterns. Eventually, I decided to be unwelcoming to bots that don't respect robots.txt, for example, Bytedance. Later, I blocked common automation tools for data scraping by their default user-agent.

The hard part is adjusting rules for the specific use case. I remind myself that simplicity prevents bugs. But with granular control, shooting yourself in the leg is easier than ever. Security is in constant conflict with usability. Therefore, it's essential to test changes.

netlify/edge-functions/firewall.ts

import type { Config, Context } from "@netlify/edge-functions"

export default async (request: Request, context: Context) => {
  const bannedBotsRegex =
    /Bytespider|ByteDance|PetalBot|Scrapy|Go-http-client|python-requests|python-httpx|axios\//i

  const userAgent = request.headers.get("user-agent") || ""
  const referer = request.headers.get("referer") || ""
  const country = context.geo?.country?.name
  const countryCode = context.geo?.country?.code
  const city = context.geo?.city
  const location = [city, country].filter(Boolean).join(", ")
  const ip = context.ip
  const url = new URL(request.url)
  const pathname = url.pathname?.toLowerCase()

  // Catch good part of total junk
  const badBot = bannedBotsRegex.test(userAgent)
  const blankUserAgent = userAgent.length === 0

  // Be careful not to block file extensions you actually use
  const bannedExtensions = [
    ".php", // most popular among scanners
    ".config",
    ".cgi",
    ".bak",
    ".asp",
    ".aspx",
    ".jsp",
    ".py",
    ".rb",
  ]

  // Any match in url, review before deploy
  const bannedKeywords = [
    ".env",
    ".git",
    ".vscode",
    ".aws",
    ".ssh",
    "/wordpress",
    "/wp-admin",
    "/wp-content",
    "/wp-includes",
  ]

  // Exact url pathnames
  const bannedPathnames = ["/admin", "/backup", "/wp"]

  // Cool Hazker detection algorithm
  const coolHazker = bannedExtensions.some((ext) => pathname?.endsWith(ext)) ||
    bannedKeywords.some((keyword) => pathname?.includes(keyword)) ||
    bannedPathnames.some((path) => pathname === path)

  // Countries
  const denyStates = []
  const bannedState = denyStates.some((state) => state === countryCode)

  // Alright, let's do something about it!
  if (bannedState || badBot || blankUserAgent || coolHazker) {
    console.log({
      message: "Blocked request 🚫",
      url: request.url,
      referer: referer,
      ua: userAgent,
      location: location,
      ip: ip,
    })
    return new Response("Access denied", {
      status: 403,
      headers: {
        "Content-Type": "text/plain; charset=utf-8",
      },
    })
  }
}

export const config: Config = {
  // Review before deploy
  path: ["/*"],
  excludedPath: ["/*.css", "/*.js"],
}

Source code - https://github.com/softbeehive/waf

Results

Around eighty percent of my visitors were rogue bots. Smoking them out at the edge is an effective approach that helped me reduce server load and keep my usage within pro plan limits.

Pros

✅ Efficient, does the job
✅ Transparent, full control of the logic
✅ Easy to customize
✅ Affordable

Cons

🍋 Redeploy on changes
🍋 Maintenance
🍋 Prone to human errors

Support

If you like this article, give WAF a star on GitHub and consider supporting my knowledge sharing efforts. Thank you!

Donate via PayPal

Protect contact email from bots

Oleksandr Bystrikov — Tue, 21 Jan 2025 13:49:41 +0000

Internet in 2025 is a wild place. A few months before writing this, I analyzed server logs and found that up to 80% of my traffic came from bots. I blocked the most aggressive by creating a web application firewall (WAF) using Netlify Edge Functions.

Make firewall rules too strict, and it will hurt legitimate visitors. So, I accept the objective reality: some bad actors will slip through.

At this point, I had to decide: let machines to be trained on my knowledge without consent or keep it private. But what if I want to make some parts of that public information less accessible to data scrapers?

Obfuscation

Keeping communication channels open comes with challenges. Adding a mailto link to your website is like welcoming spam. I don’t want to be distracted by another “quick follow-up”.

I decided to build a second layer of defense around public contact information. The web application firewall is the first layer. And on top of that, Netlify provides its default protection.

Requirements

People can copy email
Works in popular browsers
Easy to implement
Confuses rogue bots

Algorithm

Split the email address into random-length chunks.
Mix it with noise.
Hide noise using CSS.

Solution

I use Vue and render this part as static HTML at build stage.

<template>
  <div>
    <template v-for="chunk in address">
      {{ chunk }}<span class="ciao">{{ randomLetter() }}</span>
    </template>
  </div>
</template>

<script setup lang="ts">
// "contact@example.org"
const address = ["con", "tac", "t@", "e", "xam", "ple.o", "rg"]

function randomLetter() {
  return "abcdefghijklmnopqrstuvwxyz"[Math.floor(Math.random() * 25)]
}
</script>

<style scoped>
.ciao {
  display: none;
}
</style>

Try it on StackBlitz

Result

This email is shown as copy-paste friendly text in the browser. You can apply the same technique to obscure your address or phone number.

It works well at my scale. Sure, contact scrapers may evolve in the future, but interpreting CSS requires more computing resources, making it less attractive than HTML parsing.

Thanks to Spencer Mortensen for comparing email obfuscation techniques.

Support

If you like this article, consider supporting my knowledge sharing efforts and open-source work, thank you!

From zero to overkill, journey of tech founder

Oleksandr Bystrikov — Tue, 08 Oct 2024 16:06:59 +0000

Four years ago, I left my software engineering job to work on an indie project called Valisa – a travel startup that helps people find the best fares and plan their trips faster. The goal is to save travelers' time.

I want to share bits of my co-founder/solopreneur story. How we engineered it, what worked and what didn't, and why I reevaluated the company path. This can be useful to tech founders who know how to code.

In "Down and Out in Paris and London," George Orwell claimed that French restaurants thrive thanks to their sharp knives. It can well be British humor directed at their favorite neighbors. But I enjoy the idea that competitive advantage wasn't the chef's ability to mix cheese and wine.

If human experiences are Brownian motion, the journey from start to value is like riding the atom with a jetpack. Hitting other particles that affect my path is inevitable. I have an engine for maneuvering. And I must get across before running out of fuel.

Tuning engine in flight

During the lunch discussion, my friend Siarhei and I discovered that we faced exact problems while looking for affordable flights and hotels. Trip preparation requires a ton of energy and takes time.

Comparing options and booking tickets is messy due to context switching. I take notes to ensure things align and trip events make sense. But notes are an old-school solution. There is room for improvement. We decided we could automate our travel planning routine.

It took us a year to go from idea to alpha. Valisa 1.0 was a minimalist fare finder that covered European budget airlines: Ryanair and easyJet. The feedback we have received was overwhelmingly positive. We decided to focus on adding more providers and optimizing for scale.

A classic mistake? Let's dive into details so it doesn't sound like a generic statement. Our microservices were written in Go. They all served a single client – a Vue single-page app. I pre-rendered landing pages. But SPA and search engines don't play well together. JavaScript frameworks didn't have good server-side rendering support at that time.

I invested more than a month of work into switching to SSR. Nuxt 2 hydration errors annoyed me so much that I dropped it and went for an ugly wrapper that added social preview tags.

Siarhei set up Kubernetes cluster on Google Cloud. With monthly costs of around 120-140 euros, it didn't seem like a big deal. Then AWS approved our application. We got $4.000 in credits and moved all infrastructure there. Adding blows and whistles in the process, of course.

Valisa had a load balancer, Redis cache, infrastructure as code via Terraform, staging, observability, monitoring, and a Kanban board. It also had zero paying customers!

Clean code, best practices, refactoring, and optimization are pillars of our belief system, aren't they? In the eyes of an engineer, these tasks are crucial. But customers don't care about hidden details.

Lost year

In late 2021, I started working on the planner designed to complement the fare finder. By winter, we had UI mock-ups. Siarhei started implementing auth using Ruby on Rails. After several setbacks, we concluded reinventing the wheel was a terrible idea. Ory Kratos seemed a decent option, but it was dismissed due to the complexity overhead.

Events that happened after shattered all our plans. Sick neighbors invaded Ukraine full-scale in February 2022. My priorities and values shifted overnight. I got busy helping my family, friends, and random people.

Valisa was put on hold. I barely touched the code. Siarhei decided to concentrate on his full-time job. I worked as a freelancer and organized direct aid. Arguing in German, opening the locked car with a broom. None of my jobs taught me that.

Not every day do you lose your home. Stress affected my ability to think, so I had to find a way to manage my worries. It's a true paradox: simple actions like running or working ease the pressure. I discovered this built-in protection mechanism, and it helped me restart Valisa.

Product

I'm puzzled when people brag about the simplicity of their work. "I built a revolutionary app over the weekend." Is it any good? I embrace a different approach. Conservation law is never going to let you down.

Let's leave the land of flower-eating unicorns for a moment. We need to see the dark side of the moon. Adventurers know that assembling bits into a coherent travel experience is tricky.

I wanted to undo the initial system design mistakes and use isomorphic HTML rendering for SEO. Astro was the perfect choice due to Vue support. So, I started a move from SPA to TypeScript SSR.

A few months into the transition, AWS credits expired. Infrastructure bills quickly grew from 60 to 100 euros a month with no spike in usage. Amazon started charging customers for public IPs and adjusted prices for inflation.

Valisa didn't really need Kubernetes in the first place. I decided to use an opportunity to try Netlify instead. However, I had to move the web app logic and create new bugs. Siarhei deployed Go services to Cloud Run. I tested it locally and found that backend cold start time was reasonable.

In August 2024, I finished major tasks and shipped it. This caused a short downtime due to switching DNS from Route 53 to Netlify, but overall, everything was smooth. Infra costs sunk to 20 euros per month.

I have a design system based on Material 3, better fare page, registration, updated landing and copy, and much simpler architecture. As I drew the line and looked back, I realized something.

Enough of modern tech experiments. I must build the product!

Good bits

This is ten percent luck, twenty percent skill
Fifteen percent concentrated power of will
Five percent pleasure, fifty percent pain
And a hundred percent reason to remember the ~~name~~ day

– Fort Minor

Starting an indie company and embracing a healthy economic model without VC money was the best decision ever. Small teams and solopreneurs can be incredibly productive.

The Estonian e-Residency program delivered awesome onboarding. We had an excellent experience with our accounting provider. A friendly business climate makes a difference between life and death for a small company.

Something that was once a weakness can become a strength. Valisa's modern tech stack is ready for scale. Tailwind UI license is definitely worth the investment. I enjoy having a design system while building a planner.

Learnings

We are riding an atom with a jetpack. And it was engine tuning in flight. The cost of this learning is high. We committed resources to secondary tasks and played the over-engineering game. Seeing the bigger picture is way more important. I appreciate this eye-opening experience.

Focus on core product
Avoid unnecessary complexity
Reject side hustles
Done is better than perfect

Conclusion

What could be better than solving a problem that frustrated you? To find an answer, you should try. Social pressure, financial constraints, and geopolitical events affected my path. A healthy portion of adventurism and strong motivation help sail storm and still.

Samurai has no drone – only a remote control.

Innovation-friendly software

Oleksandr Bystrikov — Fri, 24 May 2024 15:05:36 +0000

Let’s face it – many established companies are live software museums. Marketing often advertises it as cutting-edge, state-of-the-art, and crème de la crème. But under the hood, in the age of AI, our world still relies on vintage technology.

Chemical terminals use 25-year-old tools that work in Internet Explorer 5 only, trains run on Windows XP, and who knows what Perls you may find in a traditional banking sector?

Why on Earth?

I have a theory: when businesses buy products or services, their expectations are proportional to the commitment. One does not simply take away a tool folks used for decades. This phenomenon is called technological inertia.

Then, one day, customers riot, demanding high-speed wi-fi on the Win XP train. You order golden routers and do a lab test. During the rollout, two million people join the network. The electric system fails. Trying to fix lights, you break doors. The release reverted via USB drive downgrade on 250 trains, 13 bricked in the process. Passengers are happy the doors work again.

Meet sunk cost fallacy: individuals or organizations may have invested heavily in the existing technology. And they are unwilling to abandon that investment, even if a new solution would be more cost-effective in the long run.

The point of no return is called don’t touch if it works. The longer it remains without a change, the more untouchable it gets. Crossing this Rubicon means an expensive and lengthy upgrade ahead.

Vehicle management at car2go

At car2go (carsharing company), I worked in the vehicle lifecycle management team. We took ownership of a relatively fresh Angular 1 single-page app developed by an external agency.

Our motivated team started making changes. I remember applying a fix that caused seven new bugs. This pattern repeated again and again. Skilled and experienced engineers could not maintain the stability bar set by the company. Only manual QA saved us because automated tests did not catch issues.

The situation was spiraling out of control. We proceeded with caution, and that slowed our progress. During retrospectives, we began questioning our course of action. Some code was relatively fresh, though the main pain point was data binding side-effects in convoluted controllers.

On the API side, challenges were more significant – multiple databases were out of sync, critical bugs in queue processing, inconsistent data, and limited observability.

Big bang is not an option

Our team concluded it was pragmatic to rethink the architecture. We needed modularity to achieve a better user experience. And a trunk-compatible system design that makes daily releases possible.

The head of engineering recognized the added value of the transition to innovation-friendlier architecture. Five engineers and a PO with QA and PM support performed zero downtime incremental upgrades that took 1.5 years to complete. For vehicle management, it was an investment that paid off.

When you operate a fleet of expensive cars, the difference between email damage tracking and an automated system could be millions of euros per year. According to my calculations, the return on investment was around 5-7x.

How to keep up with the progress?

Recently, micro-service architecture has been a subject of wide criticism. Watch this brilliant video.

Michael Paulson, aka The Primeagen, a prominent yelling tech figure, likes to mock startups for having more services than users.

The core issue is not a particular architecture. Humans associate failures with things they dislike. Be it a monolith, micro-services, or a framework. But the true killer is the complexity.

I see a repeating pattern occurring in established companies. Software is left unattended for some time. People join and leave, and priorities shift. Suddenly, a vintage marvel becomes a development blocker because multiple critical parts depend on it. Organizations invest astronomical amounts into legacy system integration.

Take action before it’s too late, and keep making changes as the product evolves. Motivated people recognize when something doesn’t work. When it happens, the lead must make a calculated decision.

How to address it?

There is a better alternative – invest in reasonable modularity. I build high-performance, innovation-friendly software that helps companies avoid expensive upgrades and legacy service pain. Estimated ROI within five years +600%.

Hire me

Does it resonate with your experience? I'm curious to hear how you integrate vintage software. And how do you keep up with the WILD pace of change in the web tooling?