Forem: Artem Verbitski

From Theory to Practice: Week 1 of Hands-On Offensive Security

Artem Verbitski — Tue, 24 Mar 2026 06:28:44 +0000

I hold a bachelor's degree in IT Security and have spent two years building fullstack web applications with React and Node.js. The theoretical foundation is solid but security is a field where hands-on practice is non-negotiable. This series documents my structured transition into offensive security, real tools, real environments, real findings.

Week one focus: environment setup, reconnaissance tooling, and web application vulnerabilities.

Environment: Kali Linux on Apple Silicon

Running security tooling on an M1 MacBook requires some deliberate setup. Native ARM support for many tools is still inconsistent, so I provisioned a Kali Linux VM using UTM a solid QEMU-based virtualisation option for Apple Silicon.

One issue worth documenting is that UTM can produce a black screen on initial Kali boot due to display driver initialisation. The fix involves adjusting the display settings before first launch. Not a blocker, but it costs time if you don't know to expect it.

With Kali running, I configured Burp Suite as an intercepting proxy with Firefox routing all traffic through it. This is the standard web application testing setup, traffic interception, modification, and analysis in one workflow.

Reconnaissance: dirb vs gospider

Two tools, two philosophies for mapping a target's attack surface.

dirb performs dictionary-based brute-force enumeration, systematically requesting common paths to discover directories and files that aren't publicly linked. One practical note:

dirb http://www.example.com   # correct
dirb http://example.com       # may produce incomplete results

Virtual hosting means www and the bare domain can resolve differently on the server side. Always specify explicitly.

gospider takes a crawler-based approach following all discoverable links from the target and mapping the visible surface. Where dirb finds what's hidden, gospider maps what's exposed. In practice, both belong in a recon workflow.

Penetration Testing Methodology

Effective penetration testing follows a structured engagement model:

Information Gathering — passive and active reconnaissance before any interaction with the target
Enumeration/Scanning — identifying live services, open ports, application fingerprints
Exploitation — leveraging identified vulnerabilities using public exploits or logic manipulation
Privilege Escalation — expanding access horizontally (lateral movement) or vertically (privilege gain)
Post-Exploitation — assessing further reachable systems, data exfiltration potential, and producing a findings report

All engagements are governed by a Rules of Engagement document the formal agreement defining scope, permitted techniques, and legal boundaries. No document, no test.

Path Traversal: Developer Perspective

Path traversal is a well understood vulnerability with a high detection rate in the wild, precisely because developers with no security background don't think about it at implementation time.

The attack vector: applications that accept a filename or path as a URL parameter can be manipulated using ../ sequences to escape the intended directory.

# Intended behaviour
GET /loadImage?filename=photo.png

# Path traversal attempt
GET /loadImage?filename=../../../etc/passwd

Common vulnerable parameters: ?file=, ?path=, ?page=, ?template=, ?doc=, ?load=

/etc/passwd is typically the first read target. It confirms exploitability and enumerates system users. From a developer's perspective, any route that accepts a user-controlled path without strict sanitisation and allowlisting is a potential vector.

Burp Suite: Intercepting and Modifying Requests

The core insight Burp Suite makes visceral: HTTP requests are not immutable. Every parameter, header, and body value that leaves the browser can be intercepted and rewritten before reaching the server.

This is obvious in theory. Seeing it in practice — modifying a live request mid-flight and observing the server's response — makes the implications concrete in a way that reading about it does not.

Week 1 Summary

Area	Status
Kali Linux (UTM, Apple Silicon)	✓ Configured
Burp Suite + Firefox proxy	✓ Intercepting live traffic
Reconnaissance tooling (dirb, gospider)	✓ Tested against own infrastructure
Pentesting methodology	✓
Path traversal	✓ Understood, tested in lab

Week 2: OWASP Top 10 in depth, XSS labs on PortSwigger Web Security Academy.

Documenting a structured transition from fullstack development into IT security. Background: BSc IT Security, 2+ years MERN stack. Follow the series at verbitski.dev.

React vs. Svelte

Artem Verbitski — Sun, 22 May 2022 13:25:34 +0000

Introduction

More and more often we hear about a relatively new web framework to develop user interfaces on web and even for mobile apps, and this is Svelte.

I don't want to write just about this technology, its pros and cons, but to compare it with the most famous web framework React, and whether it can be defeated by Svelte.

Svelte

Many developers who are starting to use this technology are very satisfied. Many of them want to keep exploring Svelte's depths and even support the project both financially and by making a contribution to the repository on Github.

But what makes Svelte stand out and make it so unique in the competition?

The main feature of Svelte is that it works as a compiler and not as a library, Svelte compiles the code into pure optimized JavaScript and does not need to drag the entire library to the production. This makes Svelte extremely fast.

React

On the other hand React, a library with rich community, developers and the huge Facebook corporation behind it.

It is currently the most popular technology within the front-end ecosystem.

Let's compare them

Which of them is more beginner friendly
Performance
Reactivity
Community
Server-side rendering
Bundle-size
Conclusion

Which of them is more beginner friendly

When we start learning something new, we always look first and estimate how much time and effort it takes to learn that or other technology. Thus, the criterion "Which is best for beginners" is important.

Both Svelte and React are not difficult to learn with JavaScript basic knowledge.

If you take React, you may need more time to study things like JSX or CSS-in-JS, although this is not something scary or incomprehensible. Below is an example of JSX syntax.

`Hello.js`

import React from "react";

const Hello = (props) => {
  const element = <h1>Hello, {props.world}!</h1>;

  return element;
};

export default Hello;

Svelte, on the other hand, is more like a simple JavaScript application, and only adds minor adjustments to HTML. Here you can see an example of Svelte syntax.

`Hello.svelte`

<script>
    let name = 'world';
</script>

<h1>Hello {name}!</h1>

<style>
  h1 {
    color: red;
  }
</style>

Performance

In this comparison, Svelte can be proud not only of its superiority over React, but many other frameworks as well.

Why is Svelte that fast?

Unlike React, Svelte does not load the entire code of the framework into the browser, but instead turns the application into a light and
optimized vanilla Javascript code on build time, and does not load the browser with unnecessary work.

Also a very bold decision from Svelte was to stop using VirtualDOM.

VirtualDOM is for a second almost the whole reason why React is fast, and allows it to reach such speeds.

But what is VDOM?

It is a copy of realDOM that is initialized with the application in the background, we specify what the interfaces should look like, and React with VDOM which is ReactDOM library, finds the best and most effective way to update realDOM - this is also called reconciliation process or diffing.

Svelte is running at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.

Reactivity

What is reactive programming?

Every developer has its own opinion about what reactivity is for them.
Here is the definition I like:

The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration

- Heinrich Apfelmus, via Michel Weststrate

But to put it very simply, we can think about it that way - when a value changes, your application should react.

If you want your application to be reactive in React, you need to add this.state or useState API, otherwise your application will not respond to changes in the values of your application. So React is not entirely reactive.

But what about Svelte?

Svelte brings reactivity in Javascript itself. It looks through your code and watches for components that depend on your variables, then updates those components as the variables change. This way, Svelte is reactive without having to rely on a third-party API.

In the example below, we declared the reactive variable doubled which will change only when the variable count is updated, so doubled is now tied to count variable.

The $ symbol in Svelte stands for Reactive declaration.

<script>
  let count = 0;
  $: doubled = count * 2;

  const handleClick = () => count += 1;
</script>

<button on:click="{handleClick}">Click me!</button>

<p>{count} doubled is {doubled}</p>

Compared to React, Svelte can be considered more reactive

Community

I think everyone already knows that React is currently the most popular framework, which means that it has many more developers who communicate, discuss and argue about this technology.

There are many more such developers, so if you need to make a web application for a client, then finding someone to write this app using React is much easier than finding someone who will use Svelte.

Another important thing is that React is supported by the huge Facebook corporation, and does not intend to disappear in the near future.

Svelte, when it used to be a hobby project by Rich Harris, recently joined the Vercel team, which is a big plus and offers great prospects for this technology.

Also, according to the State of JS 2021 survey, newcomer Svelte takes the top spot as the most loved framework. React is the most wanted, desired by one in four developers.

Server-side rendering

Server-side rendering (SSR) is the process of rendering web pages on a server and passing them to the browser (client-side),
instead of sending to the browser simple HTML page with <div id="root"></div> and then pushing all content to that div with Javascript, as we would do it with React, we are sending a full HTML page, ready to be rendered in the browser with it's full initial page content.

This approach is good for initial page loading speed and much better SEO. Also, SSR pages are optimal for users with a slow internet connection, because they can see the rendered HTML while the JavaScript is processing.

In React, there's Next.js.

Next.js is a web development framework built on top of Node.js enabling React based web applications functionalities such as server-side rendering and generating static websites. React documentation mentions Next.js among "Recommended Toolchains" advising it to developers as a solution when "Building a server-rendered website with Node.js".

On the other hand Svelte with it's SvelteKit.

SvelteKit is a full-stack, server-side, pre-rendering application framework for Svelte that can output production builds to different environments.

Next.js is a great tool because it manages to reduce the big fat React library into smaller chunks and has many smart design decisions but some clumsy ones as well. The first or second js download is 70kb, but SvelteKits initial js downloads are a fraction of that by having more features built-in.

Bundle-size

One more not less important thing is bundle-size, the smaller the bundle, the faster the page speed.

React has 42.2KB of gzipped version, but Svelte team did something unusual and made Svelte with only 1.6KB it is 26 times smaller then React, wow 😯.

Conclusion

At the end of this comparison, it may seem that Svelte is the winner, and many experienced developers say that the future is behind it. But it has to be taken with a pinch of salt, React is a good technology with a large community, and for Svelte to overshadow it, it still has a lot to grow and develop.

It would be a good advice to get familiar with Svelte and get something new out of it.

But as of 2022, the choice between Svelte and React in business will surely fall on React.

10 Popular JavaScript methods implemented from scratch

Artem Verbitski — Mon, 10 Jan 2022 11:45:50 +0000

Introduction

In this article I wanted to share with you with the most popular JavaScript methods but implemented by scratch.
A little understanding of how JavaScript methods works inside will always help you as a developer.
So these are the most popular methods in JavaScript implemented from scratch. Check this out if you are interested how JavaScript methods works inside. This is also a light version of how this work, the real method specified in ECMAScript is much more complex.

Methods mentioned on this article are:

map, reduce, filter, sort, every, includes, slice, splice, shift, indexOf.

1. map()

const fakeMap = function (callback) {
  const newArray = [];

  // 'this' refers to the array
  for (let i = 0; i < this.length; i++) {
    newArray[i] = callback(this[i], i);
  }

  return newArray;
};
Array.prototype.fakeMap = fakeMap;

[1, 2, 3].fakeMap((n) => n + 1); // output [2, 3, 4]

2. reduce()

const fakeReduce = function (callback, accumulator) {
  for (let i = 0; i < this.length; i++) {
    accumulator = callback(accumulator, this[i]);
  }
  return accumulator;
};
Array.prototype.fakeReduce = fakeReduce;

const reducer = (previousValue, currentValue) => previousValue + currentValue;

[1, 2, 3].fakeReduce(reducer, 0); // output 6

3. filter()

const fakeFilter = function (callback) {
  const newArray = [];

  for (let i = 0; i < this.length; i++) {
    if (callback(this[i])) {
      newArray.push(this[i]);
    }
  }

  return newArray;
};

Array.prototype.fakeFilter = fakeFilter;

[1, 2, 3, 4, 5].fakeFilter((n) => n > 2); // output [3, 4, 5]

4. sort()

const fakeSort = function (callback) {
  const newArray = [...this];

  for (let i = 0; i < newArray.length; i++) {
    for (let j = 0; j < newArray.length - 1; j++) {
      if (callback(newArray[j], newArray[j + 1]) > 0) {
        const temp = newArray[j + 1];
        newArray[j + 1] = newArray[j];
        newArray[j] = temp;
      }
    }
  }

  // array is sorted
  return newArray;
};

Array.prototype.fakeSort = fakeSort;

[3, 5, 1, 4, 2].fakeSort((a, b) => a - b); // output [1, 2, 3, 4, 5]

5. every()

const fakeEvery = function (callback) {
  for (let i = 0; i < this.length; i++) {
    if (!callback(this[i])) {
      return false;
    }
  }

  return true;
};

Array.prototype.fakeEvery = fakeEvery;

[1, 2, 3, 4, 5].fakeEvery((n) => n > 3); // output false

6. includes()

const fakeIncludes = function (item) {
  for (let i = 0; i < this.length; i++) {
    if (this[i] === item) {
      return true;
    }
  }

  return false;
};

Array.prototype.fakeIncludes = fakeIncludes;

[1, 2, 3, 4, 5].fakeIncludes(5); // output true

7. slice()

const fakeSlice = function (start, end) {
  let newArray = [];
  if (!end) {
    for (let i = 0; i < this.length; i++) {
      if (i >= start) {
        newArray.push(this[i]);
      }
    }

    return newArray;
  }

  for (let i = 0; i < this.length; i++) {
    if (i >= start && i <= end) {
      newArray.push(this[i]);
    }
  }
  return newArray;
};

Array.prototype.fakeSlice = fakeSlice;

[1, 2, 3, 4, 5].fakeSlice(2, 3); // output [3, 4]

8. splice()

const fakeSplice = function (start, deleteCount, ...items) {
  let newArray = [];

  // if we only provide start fakeSplice(start)
  if (!deleteCount) {
    for (let i = 0; i < this.length; i++) {
      if (i < start) {
        newArray.push(this[i]);
      }
    }
    this.length = 0;
    this.push.apply(this, newArray);
    return;
  }

  // if we only provide start and deleteCount fakeSplice(start, deleteCount)
  if (!items) {
    for (let i = 0; i < this.length; i++) {
      if (i < start || i >= start + deleteCount) {
        newArray.push(this[i]);
      }
    }

    this.length = 0;
    this.push.apply(this, newArray);
    return;
  }

  // if we provide all arguments to the function
  for (let i = 0; i < this.length; i++) {
    if (i === start + deleteCount) {
      newArray = [...newArray, ...items];
    }
    if (i < start || i >= start + deleteCount) {
      newArray.push(this[i]);
    }
  }

  this.length = 0;
  this.push.apply(this, newArray);
  return;
};

Array.prototype.fakeSplice = fakeSplice;

const planets = [
  "Mercury",
  "Venus",
  "Earth",
  "Mars",
  "Jupiter",
  "Saturn",
  "Uranus",
  "Neptune",
];
planets.fakeSplice(2, 2, "Pluto");
console.log(planets); // output ["Mercury", "Venus", "Pluto", "Jupiter", "Saturn", "Uranus", "Neptune"]

9. shift()

const fakeShift = function () {
  let newArray = [];

  for (let i = 1; i < this.length; i++) {
    newArray.push(this[i]);
  }

  this.length = 0;
  this.push.apply(this, newArray);
};

Array.prototype.fakeShift = fakeShift;
const arr = [1, 2, 3, 4, 5];

arr.fakeShift();
console.log(arr); // output [2, 3, 4, 5]

10. indexOf()

const fakeIndexOf = function (item) {
  for (let i = 0; i < this.length; i++) {
    if (item === this[i]) {
      return i;
    }
  }
  return -1;
};

Array.prototype.fakeIndexOf = fakeIndexOf;

[1, 2, 3, 4, 5].fakeIndexOf(4); // output 3

Conclusion

We just implemented the most used methods in JavaScript and get a better understanding of how they work so we can use them more effectively.

Thank you for your time!