<?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: Crygodi</title>
    <description>The latest articles on DEV Community by Crygodi (@cfcfounder).</description>
    <link>https://dev.to/cfcfounder</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%2F4073771%2Fe01fa07e-22f4-4de8-aadd-750e4181f6e6.png</url>
      <title>DEV Community: Crygodi</title>
      <link>https://dev.to/cfcfounder</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/cfcfounder"/>
    <language>en</language>
    <item>
      <title>Understanding API Fetching: What Developers Should Know About "Crackers"</title>
      <dc:creator>Crygodi</dc:creator>
      <pubDate>Thu, 13 Aug 2026 14:08:36 +0000</pubDate>
      <link>https://dev.to/cfcfounder/understanding-api-fetching-what-developers-should-know-about-crackers-510i</link>
      <guid>https://dev.to/cfcfounder/understanding-api-fetching-what-developers-should-know-about-crackers-510i</guid>
      <description>&lt;p&gt;When working with APIs, it's important to understand the difference between normal API consumption and unauthorized access.&lt;/p&gt;

&lt;p&gt;A typical application might fetch data from an API like this:&lt;/p&gt;

&lt;p&gt;fetch("&lt;a href="https://api.example.com/data" rel="noopener noreferrer"&gt;https://api.example.com/data&lt;/a&gt;", {&lt;br&gt;
  headers: {&lt;br&gt;
    "Authorization": "Bearer YOUR_TOKEN"&lt;br&gt;
  }&lt;br&gt;
})&lt;br&gt;
  .then(response =&amp;gt; response.json())&lt;br&gt;
  .then(data =&amp;gt; console.log(data));&lt;/p&gt;

&lt;p&gt;The important part is that the server controls access. The frontend can request data, but the API should verify authentication and authorization before returning anything sensitive.&lt;/p&gt;

&lt;p&gt;This becomes interesting when looking at how crackers attack poorly protected APIs.&lt;/p&gt;

&lt;p&gt;For example, a badly designed API might expose an endpoint such as:&lt;/p&gt;

&lt;p&gt;GET /api/user/123&lt;/p&gt;

&lt;p&gt;without properly checking whether the requesting user is actually allowed to access user 123.&lt;/p&gt;

&lt;p&gt;A malicious user could then change the ID:&lt;/p&gt;

&lt;p&gt;/api/user/124&lt;br&gt;
/api/user/125&lt;br&gt;
/api/user/126&lt;/p&gt;

&lt;p&gt;and potentially access information belonging to other users.&lt;br&gt;
This is a classic example of an authorization problem, often associated with IDOR (Insecure Direct Object Reference).&lt;br&gt;
The lesson isn't that fetch() itself is dangerous. The problem is trusting requests without validating them on the server.&lt;br&gt;
Developers should consider:&lt;br&gt;
Authenticate every protected request.&lt;br&gt;
Authorize access to each resource server-side.&lt;br&gt;
Never rely on hidden frontend fields for security.&lt;br&gt;
Validate user-supplied IDs and parameters.&lt;br&gt;
Avoid exposing sensitive information through public endpoints.&lt;br&gt;
Rate-limit suspicious requests.&lt;br&gt;
Log and monitor unusual API activity.&lt;br&gt;
API security ultimately comes down to one principle:&lt;br&gt;
Never assume that because your frontend hides something, a user cannot send that request manually.&lt;br&gt;
The browser is only a client. Your server must enforce the rules.&lt;br&gt;
What API security issue have you encountered that taught you an important lesson?&lt;/p&gt;

</description>
      <category>api</category>
      <category>cybersecurity</category>
      <category>javascript</category>
      <category>websecurity</category>
    </item>
    <item>
      <title>Hello DEV Community — My First Post</title>
      <dc:creator>Crygodi</dc:creator>
      <pubDate>Tue, 11 Aug 2026 21:42:18 +0000</pubDate>
      <link>https://dev.to/cfcfounder/hello-dev-community-my-first-post-2ek0</link>
      <guid>https://dev.to/cfcfounder/hello-dev-community-my-first-post-2ek0</guid>
      <description>&lt;p&gt;Hello everyone!&lt;br&gt;
This is my first post on DEV.to, so I thought I'd start by introducing myself.&lt;br&gt;
I'm a founder and full-stack developer who enjoys building products and solving real-world technical problems. My interests include backend engineering, software architecture, game development, DevOps, and experimenting with new technologies.&lt;br&gt;
I'm currently building "Crygodi Fun Club" website (&lt;a href="https://crygodi.com" rel="noopener noreferrer"&gt;https://crygodi.com&lt;/a&gt;), which has also given me the opportunity to work on real-time systems, gaming experiences, APIs, and scalable infrastructure. There have been plenty of technical challenges along the way, and I'm hoping to share some of the lessons I’ve learned from them here.&lt;br&gt;
I joined DEV.to to learn from other developers, document things I discover, and hopefully contribute something useful to the community.&lt;br&gt;
Looking forward to being part of the community.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>productivity</category>
      <category>programming</category>
      <category>crypto</category>
    </item>
  </channel>
</rss>
