DEV Community: Fongoh Martin T.

Building a Simple Blog with Supabase (Posts & Comments)

Fongoh Martin T. — Thu, 12 Feb 2026 06:27:14 +0000

In this tutorial, we will build a simple blog system using Supabase (PostgreSQL + Auth) and React with TypeScript. The goal is not to build something fancy, but to understand how authentication, database tables, and frontend logic connect together in a real application.

We will:

Set up a Supabase project
Create database tables for profiles, posts, and comments
Enable Row Level Security (RLS)
Write frontend logic for registration, login, creating posts, and commenting

This is a practical example that shows how modern backend services and frontend applications work together.

We will use a simple Posts and Comments example.

SECTION 1 – Setting Up Supabase

Step 1 – Create a Supabase Project

Go to Supabase
Click Start your project

Click Sign Up
Choose your preferred method (Email or GitHub)

After authentication, you’ll land on your backend.

Step 2 – Create a New Project

From your account dashboard:

Click New Project
Provide project name
Set database password

After the project is created, you’ll see your project dashboard.

Step 3 – Create Tables Using SQL Editor

From the left sidebar:

Click SQL Editor

Paste the following SQL:

-- Enable extension (usually already enabled in Supabase)
create extension if not exists "pgcrypto";

-- profiles (linked to auth.users)
create table profiles (
  id uuid primary key references auth.users(id) on delete cascade,
  full_name text,
  bio text,
  image_url text,
  created_at timestamp default now()
);

-- posts
create table posts (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references profiles(id) on delete cascade,
  title text not null,
  content text not null,
  image_url text,
  created_at timestamp default now()
);

-- comments
create table comments (
  id uuid primary key default gen_random_uuid(),
  post_id uuid references posts(id) on delete cascade,
  user_id uuid references profiles(id) on delete cascade,
  content text not null,
  image_url text,
  created_at timestamp default now()
);

-- ==========================
-- ENABLE ROW LEVEL SECURITY
-- ==========================

alter table profiles enable row level security;
alter table posts enable row level security;
alter table comments enable row level security;

-- PROFILES POLICIES
create policy "Users can view all profiles"
  on profiles for select
  using (true);

create policy "Users can insert own profile"
  on profiles for insert
  with check (auth.uid() = id);

create policy "Users can update own profile"
  on profiles for update
  using (auth.uid() = id);

-- POSTS POLICIES
create policy "Anyone can view posts"
  on posts for select
  using (true);

create policy "Authenticated users can create posts"
  on posts for insert
  with check (auth.uid() = user_id);

create policy "Users can update their own posts"
  on posts for update
  using (auth.uid() = user_id);

create policy "Users can delete their own posts"
  on posts for delete
  using (auth.uid() = user_id);

-- COMMENTS POLICIES
create policy "Anyone can view comments"
  on comments for select
  using (true);

create policy "Authenticated users can create comments"
  on comments for insert
  with check (auth.uid() = user_id);

create policy "Users can delete their own comments"
  on comments for delete
  using (auth.uid() = user_id);

Click Run.

Now go to Database → Tables in the sidebar.

You should see:

profiles
posts
comments

Click into each table to view structure.

You can optionally insert dummy data for testing.

Step 4 – Get API Keys and URL

API ANON KEY:

Settings > API Keys > Legacy anon, service_role API Keys (tab)

SUPABSE URL

API Docs > Introduction

These will be used in your frontend.

SECTION 2 – React + TypeScript Code

We assume a Vite + React + TypeScript setup.

Step 0 – Create Environment Variables

Before writing any code, create a .env file at the root of your project.

If you are using Vite, name it:

.env

Add the following inside it:

VITE_SUPABASE_URL=your_project_url_here
VITE_SUPABASE_ANON_KEY=your_anon_public_key_here

You can get these values from:
Settings → API → Project URL and anon public key.

Restart your development server after creating or editing the .env file.

1. Supabase Client

// src/lib/supabase.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL
const supabaseAnonKey = import.meta.env.VITE_SUPABASE_ANON_KEY

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

Assumptions for Section 2

You are using Vite + React + TypeScript
Supabase client is configured in src/lib/supabase.ts
No form validation is implemented
No styling is applied
This is purely for learning the logic

File: src/pages/Auth.tsx

This component handles both Register and Login.

import { useState } from 'react'
import { supabase } from '../lib/supabase'

export default function Auth() {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const [fullName, setFullName] = useState('')

  const handleRegister = async () => {
    const { data, error } = await supabase.auth.signUp({
      email,
      password
    })

    if (error) return alert(error.message)

    if (data.user) {
      await supabase.from('profiles').insert({
        id: data.user.id,
        full_name: fullName
      })
    }

    alert('Registered')
  }

  const handleLogin = async () => {
    const { error } = await supabase.auth.signInWithPassword({
      email,
      password
    })

    if (error) return alert(error.message)

    alert('Logged in')
  }

  return (
    <div>
      <h2>Auth</h2>

      <input placeholder="Full Name" onChange={e => setFullName(e.target.value)} />
      <input placeholder="Email" onChange={e => setEmail(e.target.value)} />
      <input placeholder="Password" type="password" onChange={e => setPassword(e.target.value)} />

      <button onClick={handleRegister}>Register</button>
      <button onClick={handleLogin}>Login</button>
    </div>
  )
}

File: src/pages/ListPosts.tsx

This component fetches and lists all posts.

import { useEffect, useState } from 'react'
import { supabase } from '../lib/supabase'

interface Post {
  id: string
  title: string
  content: string
}

export default function ListPosts({ onSelect }: { onSelect: (id: string) => void }) {
  const [posts, setPosts] = useState<Post[]>([])

  useEffect(() => {
    const fetchPosts = async () => {
      const { data } = await supabase
        .from('posts')
        .select('*')
        .order('created_at', { ascending: false })

      if (data) setPosts(data)
    }

    fetchPosts()
  }, [])

  return (
    <div>
      <h2>Posts</h2>
      {posts.map(post => (
        <div key={post.id}>
          <h3 onClick={() => onSelect(post.id)}>{post.title}</h3>
          <p>{post.content}</p>
        </div>
      ))}
    </div>
  )
}

File: src/pages/CreatePost.tsx

This component allows authenticated users to create a post.

import { useState } from 'react'
import { supabase } from '../lib/supabase'

export default function CreatePost() {
  const [title, setTitle] = useState('')
  const [content, setContent] = useState('')

  const handleCreate = async () => {
    const { data: { user } } = await supabase.auth.getUser()
    if (!user) return alert('Login first')

    await supabase.from('posts').insert({
      user_id: user.id,
      title,
      content
    })

    setTitle('')
    setContent('')
    alert('Post created')
  }

  return (
    <div>
      <h2>Create Post</h2>
      <input
        placeholder="Title"
        value={title}
        onChange={e => setTitle(e.target.value)}
      />
      <textarea
        placeholder="Content"
        value={content}
        onChange={e => setContent(e.target.value)}
      />
      <button onClick={handleCreate}>Create</button>
    </div>
  )
}

File: src/pages/PostDetails.tsx

This component:

Shows a single post
Fetches and displays comments for that post
Allows adding a new comment

import { useEffect, useState } from 'react'
import { supabase } from '../lib/supabase'

interface Post {
  id: string
  title: string
  content: string
}

interface Comment {
  id: string
  content: string
}

export default function PostDetails({ postId }: { postId: string }) {
  const [post, setPost] = useState<Post | null>(null)
  const [comments, setComments] = useState<Comment[]>([])
  const [commentText, setCommentText] = useState('')

  useEffect(() => {
    const fetchPost = async () => {
      const { data } = await supabase
        .from('posts')
        .select('*')
        .eq('id', postId)
        .single()

      if (data) setPost(data)
    }

    const fetchComments = async () => {
      const { data } = await supabase
        .from('comments')
        .select('*')
        .eq('post_id', postId)

      if (data) setComments(data)
    }

    fetchPost()
    fetchComments()
  }, [postId])

  const handleAddComment = async () => {
    const { data: { user } } = await supabase.auth.getUser()
    if (!user) return alert('Login first')

    await supabase.from('comments').insert({
      post_id: postId,
      user_id: user.id,
      content: commentText
    })

    setCommentText('')

    const { data } = await supabase
      .from('comments')
      .select('*')
      .eq('post_id', postId)

    if (data) setComments(data)
  }

  if (!post) return null

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>

      <h3>Comments</h3>
      {comments.map(c => (
        <p key={c.id}>{c.content}</p>
      ))}

      <input
        placeholder="Write comment"
        value={commentText}
        onChange={e => setCommentText(e.target.value)}
      />
      <button onClick={handleAddComment}>Add Comment</button>
    </div>
  )
}

Final Result

You now have:

Supabase project
Database tables
Authentication
Post creation
Comment system

This is a complete base-level blog system using Supabase and React.

You can now extend it with:

image uploads
protected routes

Laravel 11 Security Audit Guide (Part 3 of 3)

Fongoh Martin T. — Sat, 14 Jun 2025 06:26:08 +0000

Laravel 11 Security Audit Guide (Part 3 of 3)

Welcome to the final part of our Laravel 11 security audit series. If you’ve made it this far, you already understand the importance of hardening your app against the most common vulnerabilities.
In case you have not read the previous, you can read part 1 here and part 2 here
In this part, we’re going to cover four final security risks that many Laravel developers overlook: verbose error disclosure, missing security headers, flawed access control, and business logic abuse.

9. Verbose Error Disclosure

The Problem

Detailed error messages can be a goldmine for attackers. When exceptions throw full stack traces, database details, file paths, or even snippets of your .env file, you are exposing your internal workings. Laravel’s default error handler is very verbose in development, which is good for debugging, but dangerous in production if not configured properly.

Attackers use this information to map out your environment and identify weak points like specific packages, database credentials, or server paths.

How to Test

Force errors by visiting undefined routes or passing invalid data to endpoints.
Look for details like table names, file paths, or debug traces.

For example, visiting:

https://yourapp.com/api/user?id=abc123

Might trigger a TypeError if the system expects an integer. If the page shows you a full stack trace, it’s revealing too much.

The Fix

Set the APP_DEBUG=false and APP_ENV=production in your .env file. This will ensure Laravel shows a simple 500 error page instead of a detailed exception.

APP_ENV=production
APP_DEBUG=false

Also, consider customizing the render() method in app/Exceptions/Handler.php to log details while showing users a friendly error page.

Additional Advice

Use external logging tools like Sentry or Bugsnag.
Do not return exception messages in API responses.
Use Laravel's report() method for sensitive logging instead of exposing details in the UI.

10. Missing Security Headers

The Problem

HTTP security headers provide critical instructions to browsers about how your site should behave. Without them, your site is vulnerable to clickjacking, MIME-type sniffing, and client-side attacks like XSS.

Headers like X-Frame-Options, Content-Security-Policy, Strict-Transport-Security, and X-Content-Type-Options are commonly missing from Laravel apps unless explicitly added.

How to Test

Use your browser’s DevTools to inspect response headers.
You can also use services like securityheaders.com to quickly audit your site.

If you don’t see headers like these, it’s time to fix that:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'

The Fix

Use middleware to inject headers into every response. Create a custom middleware:

public function handle($request, Closure $next)
{
    $response = $next($request);

    $response->headers->set('X-Frame-Options', 'DENY');
    $response->headers->set('X-Content-Type-Options', 'nosniff');
    $response->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
    $response->headers->set('Content-Security-Policy', "default-src 'self'");

    return $response;
}

Additional Advice

Use a CSP library like spatie/laravel-csp for managing policies more dynamically.
Always serve your app over HTTPS to enforce HSTS.
Set Referrer-Policy and Permissions-Policy headers for additional privacy and control.

11. Flawed Access Control

The Problem

Sometimes developers forget to enforce role-based permissions, assuming that if a user is logged in, they can perform any action. This mistake can let regular users access admin routes or perform unauthorized actions like deleting other users' data.

This is not about authentication, but about authorization. Your app might know who the user is, but still fail to check if they’re allowed to do what they’re trying to do.

How to Test

Login as a non-admin user.
Try accessing URLs like /admin, /settings, or /users/delete/5.
Use Postman to call endpoints intended for other roles.

If you can perform actions or view pages meant for admins, the app has broken access control.

The Fix

Use Laravel's Gate and Policy systems. In controllers, always validate permissions like so:

$this->authorize('delete', $user);

Or use middleware for role checks:

Route::middleware(['auth', 'can:isAdmin'])->group(function () {
    Route::get('/admin', [AdminController::class, 'index']);
});

Create a custom middleware like this:

public function handle($request, Closure $next)
{
    if (auth()->user()->role !== 'admin') {
        abort(403);
    }
    return $next($request);
}

Additional Advice

Never hide routes or rely on frontend logic alone.
Test each route from every user role.
Store roles and permissions securely and check them consistently.

12. Business Logic Abuse

The Problem

Business logic flaws are subtle but dangerous. They occur when users exploit the normal flow of your application to do something unintended. For example, modifying an item’s price during checkout, placing multiple discount codes, or bypassing a payment step.

The issue isn’t about bypassing security walls, it’s about misusing allowed features in a way developers didn’t expect.

How to Test

Tamper with request payloads in Postman or your browser's DevTools.
Modify price fields, quantities, or payment flags.
Try skipping steps in a process, like completing checkout without paying.

If any of these succeed without server-side validation, you’re vulnerable.

The Fix

Always validate critical data server-side, not just in JavaScript.
Do not trust values like price, total, or is_paid from the frontend.
Recalculate values on the server before processing or storing them.

Example:

$order->total = $order->items->sum(function ($item) {
    return $item->quantity * $item->product->price;
});

Additional Advice

Set up alerts for strange user behavior like repeated refunds or excessive discounts.
Log important business actions like order confirmation, payment, and status changes.
Perform peer reviews for flows that involve money, discounts, or user roles.

This wraps up our Laravel 11 security audit series. From brute force prevention to business logic protection, securing your Laravel app is an ongoing job, not a one-time task. Regularly audit, test, and review your code as your product grows.

If you’ve found this series useful, consider sharing it with your team or dev circle. Let’s keep our ecosystems safe together.

Laravel 11 Security Audit Guide (Part 2 of 3)

Fongoh Martin T. — Sat, 14 Jun 2025 06:25:30 +0000

Laravel 11 Security Audit Guide (Part 2 of 3)

Welcome back to the second part of our Laravel 11 security audit guide. In Part 1, we tackled brute force attacks, insecure direct object references, SQL injections, and cross-site scripting. Now let’s go deeper. Part 2 focuses on four more issues that can compromise your Laravel app: CSRF, insecure file uploads, broken authentication, and missing rate limiting on APIs.

5. Cross-Site Request Forgery (CSRF)

The Problem

Cross-Site Request Forgery (CSRF) is an attack that tricks a logged-in user into making an unwanted request on a web application. Imagine a logged-in admin unknowingly clicking on a malicious link or loading an image that sends a POST request to /users/delete/12. If your Laravel app doesn’t have CSRF protection, this request could succeed.

Laravel is actually strong out of the box here, but vulnerabilities happen when developers disable or forget to use CSRF tokens, especially when creating custom forms or JavaScript-driven frontend logic.

How to Test

Login to your Laravel app as a regular user.
Create a malicious HTML form like this:

<form action="https://yourapp.com/account/delete" method="POST">
  <input type="submit" value="Click here">
</form>

Open the page in another tab where the user is still logged in.
Click the form. If the user’s account is deleted or changed without a CSRF token, you’re vulnerable.

How to Fix It

Always use Laravel’s @csrf Blade directive in forms.

<form method="POST" action="/account/delete">
  @csrf
  <button type="submit">Delete</button>
</form>

In JavaScript-driven apps, ensure you send the CSRF token in the headers:

axios.defaults.headers.common['X-CSRF-TOKEN'] = document.querySelector('meta[name="csrf-token"]').getAttribute('content');

Laravel will verify this via the VerifyCsrfToken middleware.

Additional Advice

Never disable CSRF middleware unless absolutely necessary.
Use CSRF tokens in all state-changing requests (POST, PUT, DELETE).
Educate your team about how CSRF works and what mistakes open the door to it.

6. Malicious File Uploads

The Problem

Allowing users to upload files is a major attack surface. A user could upload a PHP shell script or a crafted image file that contains hidden JavaScript. If the upload directory is publicly accessible and you don't validate file types or contents, attackers could execute malicious code or serve infected files to other users.

How to Test

Find a file upload form (like profile picture or document upload).
Upload a .php, .svg, or .html file disguised as an image.
Try to access the file from the browser after upload. If it renders or executes, you’re at risk.

The Fix

Restrict allowed file types strictly using validation rules:

$request->validate([
  'avatar' => 'required|mimes:jpg,jpeg,png|max:2048'
]);

Store files using Laravel’s Storage::put() outside of the public directory:

Storage::disk('local')->put('avatars/user123.jpg', $uploadedFile);

Never allow .php, .html, .svg, or any executable files.

Additional Advice

Scan files using a malware scanner.
Rename files using random hashes to avoid filename-based attacks.
If files must be served to the public, proxy them through a controller that checks permissions and MIME types.

7. Broken Authentication and Token Theft

The Problem

In a modern Laravel app, especially one with APIs, you might be using tokens like JWT or Laravel Sanctum for authentication. If tokens are not securely generated, stored, or transmitted, attackers can hijack sessions or impersonate users.

Tokens leaked via logs, URLs, browser storage, or unsecured APIs can be replayed from anywhere. If your token doesn’t expire or isn’t tied to a device or IP, the attacker has full access.

How to Test

Intercept a login request using a proxy tool like Burp Suite.
Extract the authentication token.
Replay the token using a different IP/device.
If the session is still valid, it means token binding is weak or missing.

The Fix

Always use HTTPS to encrypt token transmission.
Prefer HTTP-only cookies (like with Laravel Sanctum) for web auth.
Implement token expiration and refresh logic:

// Sanctum config: config/sanctum.php
'expiration' => 60, // minutes

Consider logging out sessions on token theft detection.

Additional Advice

Never store tokens in localStorage or URLs.
Log unusual token usage: IP changes, user-agent changes, or geographic anomalies.
Invalidate tokens on password changes or suspicious login patterns.

8. Missing API Rate Limiting

The Problem

Without proper rate limiting, any API endpoint is vulnerable to abuse. Attackers can flood your server with traffic, perform credential stuffing, or brute force endpoints, causing high server load or unexpected behavior.

Laravel provides a great rate limiting system, but many developers forget to use it on custom API routes.

How to Test

Identify an unauthenticated or public API endpoint.
Write a script or use a tool like Apache Bench to send 1000+ requests in a short time.
Observe if responses slow down, fail, or get accepted without delay.

The Fix

Apply Laravel’s throttle middleware to your API routes:

Route::middleware('throttle:60,1')->group(function () {
    Route::get('/public-data', [ApiController::class, 'index']);
});

This example allows 60 requests per minute.

For more control, define custom rate limiters in RouteServiceProvider:

RateLimiter::for('custom-api', function (Request $request) {
    return Limit::perMinute(30)->by($request->ip());
});

Additional Advice

Log all requests and monitor IPs with high frequency.
Use rate limiting even for authenticated users to prevent abuse.
Combine with CAPTCHA and temporary IP bans where needed.

Part 3 will cover error disclosure, security headers, access control flaws, and business logic abuse. These are often the final cracks that let attackers in.

If this helped you improve your app’s security posture, let’s connect in the comments. I’d love to hear how others are securing their Laravel apps in production.

Laravel 11 Security Audit Guide (Part 1 of 3)

Fongoh Martin T. — Sat, 14 Jun 2025 06:17:25 +0000

Laravel 11 Security Audit Guide (Part 1 of 3)

As developers and indie hackers, we often focus on shipping features fast, but security is usually an afterthought. In this 3-part series, I’ll walk you through a hands-on Laravel 11 security audit we did on a real-world app, exposing common vulnerabilities and how to fix them.

Each part will tackle four key security areas. Let’s dive into Part 1.

1. Brute Force Attacks on Login

The Problem

Brute force attacks are one of the most common and basic types of attack on any web application. These attacks happen when an attacker writes a script that tries many combinations of usernames and passwords until they find one that works. Laravel's login route (/login or /api/login) is a prime target if not properly protected. Without any rate limiting, an attacker could make thousands of login attempts per minute, eventually gaining unauthorized access to user accounts.

This isn’t just theoretical—many bots continuously scan the web looking for login forms to exploit. Even a simple email/password form can be an entry point if brute force protection is not in place.

How to Test

Use tools like Burp Suite, Hydra, or even a custom script with curl to simulate a brute force attempt.

Start with a list of common email addresses or usernames.
Use a password dictionary (like rockyou.txt) and send multiple POST requests to the login route.
Monitor the response for a successful login or for error messages that suggest rate limiting is not in place.

Example Payload (via Burp):

POST /login
Content-Type: application/x-www-form-urlencoded

email=test@example.com&password=123456

Send 10,000 of these with different passwords in a loop. If the application doesn't throttle or block them, it's vulnerable.

How to Fix It

Laravel provides built-in rate limiting using middleware. You can add the throttle middleware to limit how many attempts a user can make in a given timeframe.

Route::middleware(['throttle:5,1'])->group(function () {
    Route::post('/login', [LoginController::class, 'login']);
});

This configuration means a user can only make 5 login attempts per minute. Any more and they will receive a 429 Too Many Requests response.

For APIs, you can use Laravel's built-in api throttle via RouteServiceProvider or define custom rate limits in Route::middleware().

Additional Advice

Use Laravel's Lockout feature in LoginController.
Implement CAPTCHA after a few failed attempts.
Send alert emails on multiple failed logins from the same IP.
Log suspicious IPs and temporarily block repeat offenders.

2. Insecure Direct Object Reference (IDOR)

The Problem

IDOR vulnerabilities happen when a user can access data or functionality that they shouldn’t be able to, simply by changing the value of an identifier (like an ID in the URL). For instance, suppose you have an endpoint like /orders/123. If there’s no check in place, a user could change it to /orders/124 and view someone else’s order.

This happens when developers rely only on route model binding or Eloquent queries without checking whether the authenticated user actually owns the resource.

How to Test

Login as a regular user (say, User A).
Perform a legitimate request to /orders/123.
Change the ID in the URL to /orders/124, /orders/125, and so on.
If you’re able to view or manipulate orders that belong to another user, that’s an IDOR.

The Fix

Always verify that the current user owns the resource before showing or modifying it.

public function show($id)
{
    $order = Order::findOrFail($id);

    if ($order->user_id !== auth()->id()) {
        abort(403, 'Unauthorized access.');
    }

    return view('orders.show', compact('order'));
}

Alternatively, use Laravel's authorization system with policies:

php artisan make:policy OrderPolicy --model=Order

In OrderPolicy:

public function view(User $user, Order $order)
{
    return $user->id === $order->user_id;
}

Then in controller:

$this->authorize('view', $order);

Additional Advice

Use UUIDs instead of incremental IDs.
Obfuscate IDs on the frontend if needed.
Never trust that because a user is authenticated, they can access any model instance.

3. SQL Injection

The Problem

SQL Injection is a serious and potentially catastrophic vulnerability where an attacker can inject raw SQL commands through user input to manipulate your database. This is particularly dangerous when developers build queries using string interpolation instead of prepared statements.

Example of bad code:

$users = DB::select("SELECT * FROM users WHERE email = '$email'");

If someone enters test@example.com' OR 1=1 --, the query becomes:

SELECT * FROM users WHERE email = 'test@example.com' OR 1=1 --'

This would return all users in the database.

How to Test

Identify endpoints that include user input in SQL queries.
Use payloads like ' OR 1=1 -- or ' UNION SELECT null, version(), null -- to see if you can break the query.
Monitor database behavior or verbose error messages.

The Fix

Use Laravel’s query builder or Eloquent ORM, which uses parameter binding to prevent injection.

Safe examples:

$users = DB::select("SELECT * FROM users WHERE email = ?", [$email]);

Even better:

$user = User::where('email', $email)->first();

Laravel’s query builder escapes and binds variables by default.

Additional Advice

Never disable SQL query escaping.
Avoid raw SQL unless absolutely necessary, and if used, always bind parameters.
Use Laravel’s DB::raw() carefully and sparingly.

4. Cross-Site Scripting (XSS)

The Problem

XSS attacks occur when an attacker is able to inject malicious scripts (usually JavaScript) into pages that other users will load. These scripts can steal cookies, session tokens, or even redirect users to phishing sites.

For instance, if a user submits the following input into a comment box:

<script>alert('XSS')</script>

And your view simply renders that like:

<div>{!! $comment->body !!}</div>

It will execute in every other user’s browser that views the page.

How to Test

Submit HTML and JavaScript tags in text input fields.
Use payloads like <script>alert(1)</script> or <img src=x onerror=alert(1)>.
Observe if the script executes when the input is displayed.

How to Fix It

Always use {{ $value }} in Blade templates, not {!! !!} unless you are 100% sure the content is sanitized.
Use Laravel’s e() helper:

<div>{{ e($comment->body) }}</div>

Escape user input at output, not input.
Use libraries like HTMLPurifier if you must allow some HTML.

Additional Advice

Apply a strong Content Security Policy (CSP).
Enable browser protections by setting HTTP headers like X-XSS-Protection and Content-Security-Policy.
Avoid storing or rendering user-supplied HTML if possible.

Here is Part 2, where we’ll dive into CSRF protection, file upload vulnerabilities, token hijacking, and API rate limiting.

If you’ve experienced any of these security flaws in your Laravel apps, share your thoughts or tips in the comments!

Squash multiple commits into one

Fongoh Martin T. — Sat, 11 Jun 2022 08:00:04 +0000

"Damn, your PR has 5 commits? This is not what we agreed on right? Now, i may encounter multiple merge conflicts during rebase", code review dilemma.

When working on a project with multiple developers, git and Github is one of the mostly used tools for code collaboration.

Imagine a situation where you are working on a feature and before you are done, you 5 different commits. But then, your organizational rules says each pull request must have 1 commit. This means you have to find a way to merge all the 5 commits into 1 (squash them) and then push to your branch before making a PR. Making a PR with 1 commit could also help avoid multiple issues when pulling with rebase.

The question now is, how do you bring all 5 commits into 1.

On the branch which you want to make the PR from, do git log. This will show you all the commits you have made. It starts from the most recent commits right down to the last set of commits in your branch.
Identify the last (from the main branch) before your first commit (needed in the pr). Example

commit 5 #hash5 (pr-branch - you are here)
commit 4 #hash4 (pr-branch)
commit 3 #hash3 (pr-branch)
commit 2 #hash2 (pr-branch)
commit 1 #hash1 (pr-branch)
commit 0 #hash0 (main-branch - you want to come here)

Copy #hash0 and keep.

You now have to soft reset (reset the commits but keep the file changes) from the current commit (#hash5) to the main commit, (#hash0) by doing git reset --soft #hash0. Replace #hash0 with the hash of commit 0.
Now, if you do git status, you will see all the file changes still intact but have not yet been committed. File changes that have not been committed are in red, while file changes chat have been committed are in green (it may vary with your command line tool)
Finally, you can follow the process of git add . to add the file changes, git commit -m "One commit message summarizing everything in the 5 commits" and finally, git push origin pr-branch. If you had already pushed the commits, you may need to add a -f flag in your push command.

Tahdann, there you go, you have successfully joint (squashed) all 5 commits into 1, your PR is cleaner and the dev reviewing it will be happier and likely least number of rebase merge conflicts.

If you got any other ways, please drop them in the comments section. I'll love to read and learn more about your approach.

Copy commit from one branch to another without using git merge

Fongoh Martin T. — Fri, 20 Nov 2020 12:38:46 +0000

So I was doing some tests in code today and had to create a test branch.

After the testing was done, I forgot to change the branch back to "master". So all reasonable code that I wrote afterwards was in the test branch. I had already committed and was about to push when I noticed I was on the wrong branch.

I asked myself how I can pick a commit from one branch and apply it to another (not merging both branches together with redundant/test code). So I remembered a command that Alangi Derick used, cherry-pick

How does git cherry pick works?

While on the wrong branch (the one that has the commit), do git log and copy the commit hash
Checkout to the correct branch which you want to apply the commit, eg git checkout master
Now apply the commit to the new branch, git cherry-pick <commit-hash>

You are good to go, all the changes from that commit hash will be copied from the old branch to the new branch.

Hope this helps someone out there.

May the source be with you

Run debug and production react native app on same phone.

Fongoh Martin T. — Sat, 02 May 2020 04:05:33 +0000

When developing a mobile application in react native, we can use our phones to test the debug build. Sometimes, meeting the client, we have to build production (release apk) and show him or her. Building and installing this production release means we have to uninstall the debug from our phones.

This article shows a simple way to be able to have the same app installed twice on your device; one production release and one debug release.

This article is based on the assumption you already have a react-native project created / cloned from github.

Go to your 'android/app/build.gradle'
Locate the line which contains the app id, example

applicationId "com.xxxxxx"
Change the app id to any name, good example is using adding a .debug, eg

applicationId "com.xxx.debug"
Not a must but you can locateandroid/app/src/main/res/values/string.xml and change the name of the app <string name="app_name">MyAppName</string> to <string name="app_name">MyAppName.Debug</string>

Now each time you run android, it will install a fresh new application, not overriding any production release you have installed giving you both debug and production on same phone.

Run debug and production react native app on same phone.

Fongoh Martin T. — Sat, 02 May 2020 04:03:44 +0000

This article shows a simple way to be able to have the same app installed twice on your device; one production release and one debug release.

This article is based on the assumption you already have a react-native project created / cloned from github.

Go to your 'android/app/build.gradle'
Locate the line which contains the app id, example

applicationId "com.xxxxxx"
Change the app id to any name, good example is using adding a .debug, eg

applicationId "com.xxx.debug"
Not a must but you can locateandroid/app/src/main/res/values/string.xml and change the name of the app <string name="app_name">Digital Renter</string> to <string name="app_name">MyAppName.Debug</string>

Now each time you run android, it will install a fresh new application, not overriding any production release you have installed giving you both debug and production on same phone.