After restarting my AppSec learning journey, I decided not to jump straight into more advanced labs.
As a Frontend Engineer, I already work with APIs, requests, responses, cookies, forms and browser DevTools almost every day. So this part was not about learning HTTP from zero. It was more about refreshing the basics and looking at them through a security-focused lens.
The goal was simple: before going deeper into vulnerabilities, I wanted to make sure I understood the foundations properly.
<h2>Why I Refreshed the Basics</h2>
When learning AppSec, it is tempting to jump straight into XSS, SQL Injection, IDOR, authentication bypasses or more advanced labs.
But most web vulnerabilities still come back to simple questions:
<ul>
<li>What request is being sent?</li>
<li>What does the user control?</li>
<li>What does the server trust?</li>
<li>Is the user authenticated?</li>
<li>Is the user authorized?</li>
<li>What does the response reveal?</li>
</ul>
That is why I started with HTTP, Burp Suite, Repeater, Content Discovery and Attack Surface.
They are not the most exciting topics on paper, but they are the base layer for understanding almost everything else in web security.
<h2>HTTP Through an AppSec Lens</h2>
HTTP itself is not new to me. I work with requests and responses regularly as a Frontend Engineer, but AppSec changes the way you look at them.
In frontend work, I usually care about whether the request works, whether the API returns the right data, whether the UI updates correctly, and whether the user experience is smooth.
In AppSec, the questions are different:
<ul>
<li>Can this request be modified?</li>
<li>Can the method be changed from <code>GET</code> to <code>POST</code>, <code>PUT</code>, <code>PATCH</code> or <code>DELETE</code>?</li>
<li>Can the user change an ID in the URL or body?</li>
<li>Does the server check permissions?</li>
<li>Does the response expose more data than the UI shows?</li>
</ul>
This is a small but important mindset shift.
A request is not just something the frontend sends. It is also something an attacker can inspect, modify and replay.
<h2>User Input Is Bigger Than Form Fields</h2>
One important reminder was that user input is not only what someone types into a form.
From an AppSec point of view, the user may control much more:
<ul>
<li>URL paths,</li>
<li>query parameters,</li>
<li>request body,</li>
<li>headers,</li>
<li>cookies,</li>
<li>tokens,</li>
<li>hidden fields,</li>
<li>HTTP methods,</li>
<li>uploaded files,</li>
<li>IDs such as <code>userId</code>, <code>accountId</code> or <code>orderId</code>.</li>
</ul>
That makes the classic rule very real:
<blockquote>
Never trust user input.
</blockquote>
As frontend developers, we often validate forms in the browser. That is good for usability, but it is not enough for security.
The server still has to validate data, check the session, verify permissions and decide what the user is allowed to do.
<h2>Burp Suite Felt Familiar</h2>
<img src="https://media.daily.dev/image/upload/s--hcsmeu1k--/f_auto/v1778761467/ugc/content_38406ca0-fae1-4e0f-ace1-9b4e34f80698?_a=BAMAMiWQ0" alt="84c32f9b-f4d2-42be-a1e9-3f704903a8b2.png">
Opening Burp Suite again felt a bit like meeting an old friend.
I had already explored it last year, so the idea of intercepting requests and sending them to Repeater was not completely new. Also, because I work with APIs, browser DevTools, requests and responses in my daily job, Burp was quite easy to adapt to.
The main difference is the purpose.
In frontend development, I usually inspect requests to debug behaviour, understand data flow or check why something does not work as expected.
In AppSec, the same request becomes something to test from a trust and permission perspective.
That makes Burp feel very natural for someone with frontend experience, but it also adds a more security-focused way of thinking.
<h2>Repeater: Small Changes, Big Lessons</h2>
Repeater is one of the tools I enjoyed the most.
The concept is simple: take a request, modify it, resend it and compare the response, but small changes can teach a lot.
For example:
<pre><code>GET /profile?id=123
</code></pre>
can become:
<pre><code>GET /profile?id=124
</code></pre>
Or a request method can be changed:
<pre><code>GET /api/users/123
</code></pre>
to:
<pre><code>DELETE /api/users/123
</code></pre>
The point is not to randomly break things. The point is to understand whether the server is checking access properly.
A secure server should not trust the client just because the request looks normal.
<h2>Content Discovery and Hidden Paths</h2>
Another important topic was Content Discovery.
The application is often bigger than what is visible in the menu.
There may be:
<ul>
<li>admin panels,</li>
<li>old endpoints,</li>
<li>API routes,</li>
<li>backup files,</li>
<li>upload folders,</li>
<li>test pages,</li>
<li>hidden directories,</li>
<li>paths listed in <code>robots.txt</code> or <code>sitemap.xml</code>.</li>
</ul>
One of the key lessons here is:
<blockquote>
A hidden URL is not security.
</blockquote>
If <code>/admin</code> is not linked in the UI, that does not mean it is protected. If <code>/backup.zip</code> is not visible in the navigation, that does not mean nobody can find it.
Security should come from proper authentication, authorization and configuration, not from hoping that nobody guesses the URL.
<h2>Understanding Attack Surface</h2>
Attack surface means all the places where an application can be attacked or abused.
That includes:
<ul>
<li>login,</li>
<li>registration,</li>
<li>password reset,</li>
<li>file upload,</li>
<li>forms,</li>
<li>API endpoints,</li>
<li>URL parameters,</li>
<li>cookies,</li>
<li>headers,</li>
<li>admin panels,</li>
<li>public directories,</li>
<li>third-party integrations,</li>
<li>old endpoints,</li>
<li>subdomains.</li>
</ul>
This topic helped me connect everything together.
HTTP shows how the application communicates.
Burp shows how to inspect and modify that communication.
Content Discovery helps find more places to test.
Attack Surface helps understand where risk may exist.
<h2>My Practical Checklist Going Forward</h2>
<img src="https://media.daily.dev/image/upload/s--Bu9NfqTP--/f_auto/v1778761495/ugc/content_3a445d8b-8ced-4652-96c7-4ed80dc8f747?_a=BAMAMiWQ0" alt="d35055a8-6c74-43e0-a207-1987d55b04db.png">
<h2></h2>
After refreshing these fundamentals, my checklist for future labs is simple:
<ul>
<li>What request is being sent?</li>
<li>What HTTP method is used?</li>
<li>Can the method be changed?</li>
<li>What values are controlled by the user?</li>
<li>Are there IDs in the URL, query string or body?</li>
<li>Is the user authenticated?</li>
<li>Is the user authorised?</li>
<li>What does the server return?</li>
<li>Does the response expose more data than needed?</li>
<li>Are there hidden paths or old endpoints?</li>
<li>Is this feature part of the attack surface?</li>
</ul>
This is the foundation I want to build on before moving deeper into specific vulnerabilities.
<h2>Final Thoughts</h2>
This stage was not about learning flashy attacks.
It was about building the right base.
As a Frontend Engineer, I already understand a lot about how web applications work from the client side. Now I am trying to connect that knowledge with AppSec thinking: trust boundaries, server-side validation, authorisation, request manipulation and attack surface.
The more I learn, the more I see that AppSec is not only about tools or payloads.
It is about asking better questions.
FYI, my notes can be found on the link below:
<a href="https://github.com/cieslikprzemyslaw/cybersecurity/tree/master/ENG/01-web-appsec-fundamentals" target="_blank" rel="noopener nofollow">https://github.com/cieslikprzemyslaw/cybersecurity/tree/master/ENG/01-web-appsec-fundamentals</a>
#appsec #security #cyber #career

A practical AppSec learning journal from a Frontend Developer. I share notes, lab write-ups, OWASP topics, Burp Suite practice, and honest thoughts from learning web security step by step.

Application Security Blog

A frontend engineer shares their AppSec learning journey, focusing on foundational concepts before diving into advanced vulnerabilities. Covers how to view HTTP requests through a security lens, using Burp Suite and its Repeater tool to inspect and modify requests, content discovery techniques for finding hidden endpoints, and understanding attack surface. Includes a practical checklist for evaluating web application security during testing.

HTTP, Burp Suite and Attack Surface: My AppSec Foundations