<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Jesse Ochoi</title>
    <description>The latest articles on DEV Community by Jesse Ochoi (@jesse_ochoi).</description>
    <link>https://dev.to/jesse_ochoi</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4229329%2F7314358b-89c8-4b50-bbfe-f388a04f3fd5.jpg</url>
      <title>DEV Community: Jesse Ochoi</title>
      <link>https://dev.to/jesse_ochoi</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/jesse_ochoi"/>
    <language>en</language>
    <item>
      <title>What I Learned About Web Application Security: Threat Modelling a PHP Invoice Application</title>
      <dc:creator>Jesse Ochoi</dc:creator>
      <pubDate>Thu, 05 Nov 2026 22:26:58 +0000</pubDate>
      <link>https://dev.to/jesse_ochoi/what-i-learned-about-web-application-security-threat-modelling-a-php-invoice-application-17d3</link>
      <guid>https://dev.to/jesse_ochoi/what-i-learned-about-web-application-security-threat-modelling-a-php-invoice-application-17d3</guid>
      <description>&lt;p&gt;I'm currently developing my skills in software engineering, networking and cybersecurity. As part of my learning journey, I recently completed a practical threat-modelling exercise using a PHP/MySQL invoice application as a case study.&lt;br&gt;
The goal wasn't simply to learn security terminology. It was to understand how attackers might target a web application and how developers can reduce those risks.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1. Identifying potential threats&lt;/strong&gt;&lt;br&gt;
&lt;strong&gt;Brute-force attacks&lt;/strong&gt;&lt;br&gt;
An attacker repeatedly attempts different passwords to compromise an administrator account.&lt;br&gt;
Potential defence: Login rate limiting, progressive delays and monitoring.&lt;br&gt;
&lt;strong&gt;SQL injection&lt;/strong&gt;&lt;br&gt;
An attacker manipulates application input to interfere with database queries.&lt;br&gt;
Potential defence: Prepared SQL statements and appropriate database permissions.&lt;br&gt;
&lt;strong&gt;Broken access control&lt;/strong&gt;&lt;br&gt;
An unauthenticated user attempts to access protected pages, such as an administrator dashboard.&lt;br&gt;
Potential defence: Server-side session checks and authorization on every protected resource.&lt;br&gt;
&lt;strong&gt;Session hijacking&lt;/strong&gt;&lt;br&gt;
An attacker obtains an administrator's active session cookie and attempts to impersonate that administrator.&lt;br&gt;
Potential defence: HTTPS, secure cookie attributes, session expiration and proper session management.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;2. Understanding browser cookie security&lt;/strong&gt;&lt;br&gt;
I studied three important cookie attributes:&lt;br&gt;
• HttpOnly: Prevents JavaScript from directly reading the cookie.&lt;br&gt;
• Secure: Restricts cookie transmission to HTTPS.&lt;br&gt;
• SameSite: Helps mitigate cross-site request forgery (CSRF).&lt;br&gt;
One particularly important lesson was that HttpOnly does not completely prevent session abuse.&lt;br&gt;
A browser can automatically attach eligible session cookies to requests. Therefore, malicious JavaScript running in an application's origin may still perform actions using the authenticated browser session, even when it cannot directly read the cookie.&lt;br&gt;
This helped me understand why preventing XSS and securing sessions must work together.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;3. Key lessons&lt;/strong&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt; Authentication and authorization are different security concepts.&lt;/li&gt;
&lt;li&gt; Server-side validation is essential.&lt;/li&gt;
&lt;li&gt; Prepared statements help prevent SQL injection.&lt;/li&gt;
&lt;li&gt; Rate limiting helps reduce brute-force attacks.&lt;/li&gt;
&lt;li&gt; Cookie security requires multiple defensive layers.&lt;/li&gt;
&lt;li&gt; XSS can remain dangerous even when session cookies use HttpOnly.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;4. What comes next?&lt;/strong&gt;&lt;br&gt;
My next step is to move beyond theoretical threat modelling and examine how these protections can be implemented and tested in a PHP application.&lt;br&gt;
I'm documenting each completed exercise as part of my journey towards becoming a stronger software engineer with practical cybersecurity knowledge.&lt;br&gt;
Question for the community:&lt;br&gt;
What's one web application security mistake you commonly see beginner developers make?&lt;/p&gt;

</description>
      <category>cybersecurity</category>
      <category>php</category>
      <category>webdev</category>
      <category>learning</category>
    </item>
  </channel>
</rss>
