DEV Community: Golam Mostafa

Self-Hosted vs. Managed: Coolify Against Vercel, Heroku, Netlify, and Railway

Golam Mostafa — Mon, 15 Jun 2026 18:49:59 +0000

How our team thought through whether to run our own deployment platform or keep paying for someone else's. Pricing and feature details verified June 2026 — these change often, so we always recheck the vendor's pricing page before committing.

Why we wrote this

If we ship web apps, we eventually hit the same fork in the road. We can hand our infrastructure to a managed Platform-as-a-Service (PaaS) — Vercel, Heroku, Netlify, Railway — and pay a monthly bill that scales with usage. Or we can run an open-source, self-hostable PaaS like Coolify on a server we own and pay only for the hardware.

The managed platforms give us convenience: we push our code, and global infrastructure, scaling, SSL, and databases are handled. The self-hosted route gives us control and a flat, predictable cost — at the price of doing our own operations.

This post breaks down what each managed platform actually does, what it costs, and where it shines or stings. Then it does the same for Coolify, and finishes with a clear "what we can and cannot do" view of each side.

First, the two models in one paragraph

A managed PaaS abstracts the server away entirely. We never SSH into a machine; we push to Git and the platform builds, deploys, scales, and serves our app from its own infrastructure. We pay per seat, per usage, or both. A self-hosted PaaS like Coolify is a control panel we install on our own VPS or bare metal. It gives us the same git-push-to-deploy experience, automatic SSL, and a dashboard — but the servers, the uptime, the backups, and the security patching are ours to own. The software is free; the server is our only bill.

Vercel

What it is: The frontend platform of choice for Next.js and modern JavaScript frameworks. Vercel is built around serverless functions, a global edge network, and an exceptional developer experience.

What we can do with it:

Push to Git and get automatic builds, preview URLs for every pull request, and instant production deploys.
Serve from a global edge CDN with very low latency worldwide.
Run serverless functions and edge middleware close to our users.
Use Next.js-specific features like Incremental Static Regeneration (ISR), image optimization, and edge config.
Automatic HTTPS/SSL and zero-config deployments.

Pricing (June 2026):

Hobby — free, but non-commercial only. If our app earns money, Vercel requires an upgrade.
Pro — $20 per user per month, with $20 of usage credit per seat and 1 TB of bandwidth included. A 5-person team pays $100/month in seats before any traffic.
Enterprise — custom pricing, often starting in the five-figures-per-year range, with SSO, SLAs, and audit logs.

What to watch: Vercel's real cost is usage-based and can catch us off guard. Above the included tiers, we pay for Fast Data Transfer (~$0.15/GB), Edge Requests (~$2 per million), function execution, and image optimization. A growing SaaS app can run a few hundred dollars a month. On the free Hobby plan, hitting the limits takes the site offline until the next billing cycle rather than charging overages.

Best for: Frontend-heavy teams, Next.js apps, and anyone who values speed-to-ship and global performance over infrastructure control.

Heroku

What it is: The platform that popularized git-push deployment back in 2007. Now owned by Salesforce, it remains a polished, full-stack PaaS — but it's no longer cheap, and the free tier is gone.

What we can do with it:

Deploy full-stack apps in nearly any language using "dynos" (its container units).
Attach a large ecosystem of add-ons (Postgres, Redis, monitoring, etc.) with a few clicks.
Scale horizontally by adding more dynos (on Standard tier and above).
Tight Salesforce integration via Heroku Connect for teams in that ecosystem.

Pricing (June 2026) — no free tier:

Eco — $5/month for 1,000 dyno hours shared across the account; dynos sleep after 30 minutes of inactivity. Good for hobby/non-production.
Basic — $7/month per dyno, always-on, no sleep.
Standard — $25–$50/month per dyno, with horizontal scaling, metrics, and preboot.
Performance — $250–$500/month per dyno for high-traffic, dedicated workloads.
Add-ons billed separately: Postgres, Redis, and others stack on top of dyno costs.

What to watch: Costs compound fast because dynos, databases, Redis, and add-ons are each billed independently. The filesystem is ephemeral (data is wiped on restart), which forces adoption of managed Postgres/Redis. Enterprise pricing is opaque and negotiated.

Best for: Teams that value a mature, battle-tested platform and simplicity over cost, especially those already in the Salesforce ecosystem.

Netlify

What it is: The Jamstack pioneer — built for static sites, frontend apps, and serverless functions, with Git-based CI/CD and a built-in CDN.

What we can do with it:

Deploy static sites and frontend frameworks with Git-based continuous deployment.
Get unlimited deploy previews, custom domains with SSL, and form handling out of the box.
Run serverless functions and edge functions.
Use a managed Postgres database and basic firewall rules even on the free tier.

Pricing (June 2026) — credit-based model:

Free — $0, with 300 credits/month, 100 GB bandwidth, 300 build minutes, custom domains, and unlimited preview deploys. Genuinely usable for small sites.
Personal — $9/month with 1,000 credits.
Pro — $20/month flat with 3,000 credits and, as of April 2026, unlimited team seats (Netlify dropped per-seat pricing).
Enterprise — custom pricing for compliance and advanced security.

What to watch: The credit model bundles bandwidth, build minutes, and function invocations into one allowance — flexible, but it takes a minute to reason about. Exceed credits and we auto-recharge (paid plans) or the site pauses (free plan). Complex backends aren't its strength.

Best for: Static sites, Jamstack apps, content-heavy frontends, and small teams that want a generous free tier and flat team pricing.

Railway

What it is: A modern, usage-based PaaS positioned as the cleaner, cheaper answer to Heroku's dyno model. Strong developer experience, native databases, and billing that tracks actual usage.

What we can do with it:

Auto-detect our stack and deploy with near-zero config (Next.js, Django, Rails, Rust, and more).
Spin up PostgreSQL, MySQL, MongoDB, or Redis with one click — billed as part of usage.
Get preview environments per pull request, an environment-variables UI, logs, and metrics.
Set hard monthly spend caps (Pro) so the bill can't run away.

Pricing (June 2026) — usage-based with included credits:

Trial — no permanent free tier; a 30-day trial with $5 one-time credit, no card required.
Hobby — $5/month, which includes $5 of usage credits (single-developer workspaces).
Pro — $20/month, including $20 of credits, unlimited workspace seats, and spend limits.
Enterprise — custom, with a ~$2,000/month minimum, plus compliance (HIPAA/SOC 2), dedicated infra, and BYOC.

What to watch: Usage-based billing rewards efficiency but trades predictability — a database-heavy app can exceed its credit allowance, so we'd keep an eye on the usage dashboard. Most real production apps land around $20–$50/month.

Best for: Developers and startups who want Heroku-like simplicity with modern, consumption-based pricing and don't mind monitoring usage.

Coolify — the self-hosted option

What it is: An open-source, self-hostable PaaS (Apache 2.0 license) that we install on any server with an SSH connection — a VPS, bare metal, a Raspberry Pi, even an old laptop. It hit a stable v4.0 in 2026, has 55,000+ GitHub stars, and is the most popular self-hosted PaaS available. The community has shifted from calling it a "Heroku alternative" to a "self-hosted Vercel."

What we can do with it:

Git push to deploy from GitHub, GitLab, Bitbucket, or Gitea — including self-hosted Git.
Automatic, auto-renewing SSL via Let's Encrypt for our custom domains.
One-click deploy of 280+ services — databases (PostgreSQL, MySQL, MongoDB, Redis, ClickHouse), workflow tools (n8n), and more — plus anything that runs in Docker.
Multi-server orchestration from a single dashboard.
Preview deployments per branch — including the backend and per-branch databases, which Vercel itself can't do.
Automatic database backups to any S3-compatible storage.
A powerful API, a CLI, and a browser-based real-time terminal for managing servers without leaving the dashboard.
Team collaboration with roles and permissions, monitoring, and notifications via Discord, Telegram, or email.
No vendor lock-in — all settings live on our own server.

Pricing (June 2026):

Self-hosted — free forever, all features included, no per-seat fees and no feature gates. We pay only for the server. A capable VPS (e.g., Hetzner, ~4 vCPU / 8 GB RAM) runs roughly $6–$25/month. Real-world reports describe dropping from ~$150/month on managed platforms to under $30/month.
Coolify Cloud — $5/month for up to 2 connected servers (+$3/month per additional server), with a 20% annual discount. Important nuance: Cloud manages the Coolify control plane (the dashboard, updates, backups) — we still bring and pay for our own servers.

Where it falls short — the honest cons:

No global edge network or CDN. Our app runs in one region unless we put Cloudflare (or similar) in front of it.
No Incremental Static Regeneration and no edge-middleware runtime. If we rely on Vercel-specific edge features, we'd need to rewrite them.
No true serverless "scale to zero." Coolify runs long-lived containers and has a minimum footprint (roughly 2 CPU / 2 GB RAM), so it's not a FaaS replacement. (For functions, we'd pair it with something like Supabase, Cloud Run, or Lambda.)
No built-in observability. No analytics, error tracking, session replay, or uptime monitoring out of the box — a production-grade observability stack adds roughly $150+/month if we want it.
We own the operations. Patching, uptime, scaling decisions, and security are on us. A single-server setup is a single point of failure; real production needs multi-server planning.
Security and compliance are our responsibility. Coolify has had at least one CVE on record and is generally not a fit out-of-the-box for regulated SOC 2 / HIPAA workloads.
There's a learning curve if our team is light on DevOps/Docker experience.

Best for: Technically capable teams like ours that want full infrastructure control, data sovereignty, predictable flat costs, and freedom from vendor lock-in — and have (or are willing to build) the DevOps bandwidth to run it.

Head-to-head at a glance

Dimension	Vercel	Heroku	Netlify	Railway	Coolify
Model	Managed	Managed	Managed	Managed	Self-hosted
Primary strength	Frontend / Next.js	Full-stack, mature	Jamstack / static	Full-stack, usage-based	Full control, any Docker app
Free tier	Yes (non-commercial)	No	Yes (generous)	Trial only ($5)	Software free; pay for server
Entry paid price	$20/user/mo	$5/mo (Eco)	$9/mo (Personal)	$5/mo (Hobby)	~$6–25/mo (VPS)
Pricing predictability	Usage can spike	Stacks fast	Credit-based	Usage-based	Flat / predictable
Global edge CDN	Yes	No (single region)	Yes	No (single region)	No (add Cloudflare)
Serverless functions	Yes	Limited	Yes	Via services	Not native (workarounds)
Scale to zero	Yes	Eco sleeps	Yes	Yes	No
Managed databases	Add-on	Add-on	Postgres included	One-click, native	We run them (or connect Neon, etc.)
Built-in observability	Yes	Add-ons	Some	Yes	No (add our own)
Backend / long-running jobs	Limited	Yes	Limited	Yes	Yes
Per-branch backend + DB previews	No	No	No	Partial	Yes
Data sovereignty / on-prem	No	No	No	BYOC (Enterprise)	Yes (fully)
Vendor lock-in	High	High	Medium	Medium	None
Ops burden on us	None	None	None	None	High

What we CAN and CANNOT do: paid platforms vs. Coolify

With the paid platforms, we CAN:

Ship globally with edge CDNs and serverless functions with effectively zero operations work.
Auto-scale from zero to large traffic spikes without touching a server.
Lean on managed databases with built-in backups and high availability.
Get compliance certifications (SOC 2, HIPAA on higher tiers), DDoS protection, and SLAs.
Use platform-specific magic — Vercel's ISR and edge middleware, Netlify's form handling, Heroku's add-on marketplace.

With the paid platforms, we CANNOT (easily):

Predict the bill with certainty once usage scales — costs are tied to traffic, seats, and execution.
Keep our data fully on our own infrastructure or on-premises (except Railway/others' enterprise BYOC).
Escape vendor lock-in — platform-specific features mean migration has real switching costs.
Run arbitrary long-lived or unusual workloads cheaply (serverless timeouts and per-resource billing get in the way).

With Coolify, we CAN:

Run unlimited apps and databases on one server for a flat, predictable monthly cost.
Deploy any Docker-compatible service, plus 280+ one-click templates.
Keep 100% of our data on infrastructure we own — full sovereignty, no lock-in.
Get git-push deploys, auto-SSL, multi-server management, and per-branch previews that include the backend and a database.
Run long-lived processes (schedulers, bots, AI pipelines) that serverless timeouts would kill.

With Coolify, we CANNOT (without extra work):

Serve from a global edge network or use true serverless scale-to-zero out of the box.
Get built-in analytics, error tracking, or uptime monitoring (we assemble our own stack).
Offload operations — uptime, patching, scaling, and security are our team's job.
Treat it as turnkey for regulated SOC 2 / HIPAA workloads without significant hardening.
Use Vercel-/Netlify-specific edge features without rewriting them.

So which should we choose?

There's no universal winner — it depends on what we're optimizing for.

Vercel — when we live in the Next.js/frontend world and want the best developer experience and global performance, and we accept usage-based billing.
Netlify — when we build Jamstack/static sites and want a genuinely generous free tier and flat team pricing.
Heroku — when we want a mature, simple, full-stack platform and cost is secondary to reliability and the add-on ecosystem.
Railway — when we want Heroku-style simplicity with modern, pay-for-what-we-use pricing and native databases.
Coolify — when we have (or want to build) the DevOps capability, value control and data ownership, and want to convert a variable cloud bill into a flat, low server cost — which is exactly our case as we deploy our own services on our own infrastructure.

The honest summary: the managed platforms give us time and zero operations; Coolify gives us control and a low, predictable cost. The right answer is whichever of those two our team is shorter on.

Pricing and feature details reflect June 2026 and are subject to change. We verify current numbers on each vendor's pricing page before making a decision.

I state "You will love it - React Query".

Golam Mostafa — Wed, 08 Oct 2025 04:29:29 +0000

🚀 ভালো লাগার আরও একটি utility: React Query

React Query use করলে API fetch, cache, update সব সহজ। RTK Query ঠিক আছে, কিন্তু complex scenario-এ clumsy হতে পারে।

👉 API Fetching সহজ

const { data, isLoading, error } = useQuery(['todos'], fetchTodos)

শুধু useQuery বা useMutation call করতে হবে।
Background-এ fetch, retry, error handling auto।

RTK Query: Multiple queries বা complex retry verbose।

👉 Caching & Stale Data

const { data } = useQuery(['projects', page], fetchProjects, {
  staleTime: 5000,
  keepPreviousData: true
})

Flicker কমায়, pagination smooth।

RTK Query: Requires more manual work than React Query.

👉 Updating & Mutations

const mutation = useMutation(updateTodo, {
  onSuccess: () => queryClient.invalidateQueries(['todos'])
})

onSuccess, onError, onSettled দিয়ে cache automatically invalidate।

RTK Query: Tag system use করতে হয়, একটু verbose।

👉 Offline / Window Focus Handling

refetchOnWindowFocus → user active করলে fresh data।
Retry automatically network fail হলে।

RTK Query: Manual setup দরকার।

👉 File Uploads & Non-serializable Data

React Query supports File, FormData direct use।

RTK Query: ❌ serializable restriction → tricky। Cache Redux store-এ → File, FormData, Date support নেই।

👉 Multiple Queries & Dependent Queries

const { data: user } = useQuery(['user', userId], getUser)
const { data: projects } = useQuery(
  ['projects', user?.id],
  getProjects,
  { enabled: !!user?.id }
)

একসাথে multiple query handle করা সহজ।

RTK Query: conditional skip করতে হয় → কম intuitive।

👉 API Error Handling & Conditional Invalidate

useMutation(updateData, {
  onSuccess: () => queryClient.invalidateQueries(['todos']),
  onSettled: () => queryClient.invalidateQueries(['todos']) // success/error উভয়েই
})

Default: error হলে invalidate হয় না। চাইলে onSettled use করে success বা error উভয়েই invalidate করা যায়।

RTK Query: conditional invalidate করতে extra code লাগে → beginner-unfriendly।

👉 Optimistic Updates

useMutation(updateTodo, {
  onMutate: async (newTodo) => {
    await queryClient.cancelQueries(['todos'])
    const previousTodos = queryClient.getQueryData(['todos'])
    queryClient.setQueryData(['todos'], old => [...old, newTodo])
    return { previousTodos }
  },
  onError: (err, newTodo, context) => {
    queryClient.setQueryData(['todos'], context.previousTodos)
  }
})

UI instantly update, error হলে rollback।

RTK Query: onQueryStarted + updateQueryData → more complex।

👉 Infinite Queries (Infinite Scroll)

const { data, fetchNextPage, hasNextPage } = useInfiniteQuery(
  ['projects'],
  fetchProjects,
  { getNextPageParam: (lastPage) => lastPage.nextCursor }
)

Next page automatic track।

RTK Query: Manual setup বা complex pattern।

⭐ Awesome Devtools

React Query devtools দিয়ে সব status (fetching, stale, active, etc.) দেখতে পারবেন। Debugging অনেক সহজ।

💡 Conclusion:
I have used both RTK and React Query. But find that React Query is much simpler than RTK 😊.

DOCUMENTATION

Web LLM attacks

Golam Mostafa — Sat, 15 Feb 2025 13:57:51 +0000

Let's explore how to secure your LLM applications using JavaScript, with simple examples and clear explanations.

1. Understanding the Attack Surface

When you build an app with LLMs, you typically have this setup:

Users send inputs to your app
Your app talks to the LLM service (like OpenAI or Claude)
The LLM connects to other parts like databases and files

Common Attack Vectors:

Direct API Manipulation

// ❌ Vulnerable Implementation
function processUserRequest(userInput) {
    const llmResponse = await llm.generate(userInput);
    const filename = llmResponse.filename;
    return fs.readFileSync(filename); // Dangerous!
}

// ✅ Secure Implementation
function processUserRequest(userInput) {
    const llmResponse = await llm.generate(userInput);
    const filename = llmResponse.filename;

    // Check if path is safe
    if (!isSafePath(filename)) {
        throw new Error("Invalid file path");
    }

    // Use path sanitization
    const safePath = sanitizePath(filename);
    return fs.readFileSync(safePath);
}

Hidden Prompt Injection

// Example of checking for hidden content
function checkForHiddenContent(userInput) {
    // Remove HTML tags
    const strippedInput = userInput.replace(/<[^>]*>/g, '');

    // Check for suspicious keywords
    const suspiciousPatterns = [
        'ignore previous',
        'system prompt',
        'you are now'
    ];

    return !suspiciousPatterns.some(pattern => 
        strippedInput.toLowerCase().includes(pattern)
    );
}

2. Security Best Practices

2.1 Secure API Wrapper

class SecureAPIWrapper {
    constructor(llmClient) {
        this.llm = llmClient;
        this.allowedApis = new Set(['getPublicData', 'processText']);
        this.rateLimiter = new RateLimiter();
        this.logger = new AuditLogger();
    }

    async executeApiCall(apiName, params) {
        // Check if API is allowed
        if (!this.allowedApis.has(apiName)) {
            throw new Error("Unauthorized API access");
        }

        // Clean parameters
        const cleanParams = this.sanitizeParams(params);

        // Check rate limit
        if (!await this.rateLimiter.canMakeRequest()) {
            throw new Error("Rate limit exceeded");
        }

        // Log the call
        this.logger.logApiCall(apiName, cleanParams);

        // Make the actual API call
        return await this.llm.callApi(apiName, cleanParams);
    }
}

2.2 Protecting Sensitive Data

class DataProtector {
    constructor() {
        this.patterns = {
            email: /\b[\w\.-]+@[\w\.-]+\.\w{2,}\b/,
            ssn: /\d{3}-\d{2}-\d{4}/,
            creditCard: /\d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4}/
        };
    }

    sanitizeText(text) {
        let cleanText = text;

        // Replace each pattern with [REDACTED]
        Object.entries(this.patterns).forEach(([type, pattern]) => {
            cleanText = cleanText.replace(pattern, `[REDACTED ${type}]`);
        });

        return cleanText;
    }
}

// Usage example
const protector = new DataProtector();
const userInput = "My email is user@example.com and CC: 1234-5678-9012-3456";
console.log(protector.sanitizeText(userInput));
// Output: "My email is [REDACTED email] and CC: [REDACTED creditCard]"

3. Security Monitoring

class SecurityMonitor {
    constructor() {
        this.events = [];
    }

    logEvent(eventType, severity, details) {
        const event = {
            timestamp: new Date(),
            type: eventType,
            severity,
            details,
        };

        this.events.push(event);

        // If high severity, send alert
        if (severity === 'high') {
            this.sendAlert(event);
        }
    }

    async sendAlert(event) {
        // Send to your monitoring service
        await fetch('your-monitoring-endpoint', {
            method: 'POST',
            body: JSON.stringify(event)
        });
    }
}

4. Security Checklist

✅ Always implement these safety measures:

Input Validation
- Validate all user inputs
- Set maximum length limits
- Check for malicious patterns
API Security
- Use secure API keys
- Implement rate limiting
- Log all API calls
Data Protection
- Remove sensitive information
- Encrypt data in transit
- Regularly check security logs

Example Implementation

class SecureLLMApp {
    constructor() {
        this.apiWrapper = new SecureAPIWrapper(llmClient);
        this.dataProtector = new DataProtector();
        this.monitor = new SecurityMonitor();
    }

    async processUserRequest(userInput) {
        try {
            // 1. Validate input
            if (!checkForHiddenContent(userInput)) {
                throw new Error("Suspicious content detected");
            }

            // 2. Sanitize sensitive data
            const cleanInput = this.dataProtector.sanitizeText(userInput);

            // 3. Make API call
            const response = await this.apiWrapper.executeApiCall(
                'processText', 
                { text: cleanInput }
            );

            // 4. Log success
            this.monitor.logEvent('request_processed', 'info', {
                inputLength: userInput.length
            });

            return response;

        } catch (error) {
            // Log any errors
            this.monitor.logEvent('request_failed', 'high', {
                error: error.message
            });
            throw error;
        }
    }
}

Remember

Always validate user inputs
Keep your security measures updated
Monitor for unusual behavior
Regularly test your security setup

Acknowledgment: This document references information from PortSwigger Web Security.

Prevent Authentication Security Issues

Golam Mostafa — Fri, 14 Feb 2025 17:55:23 +0000

Use Strong Passwords
- Enforce strong password policies. Use a password strength checker like zxcvbn to guide users in creating secure passwords.
- Example: If a user tries "password123," the system should suggest using "MyStr0ng#Pass2025" instead.
Prevent Username Enumeration
- Return the same error message and HTTP status code for invalid usernames and passwords to avoid revealing whether a username exists.
- Example: Show "Invalid credentials" for both wrong usernames and passwords, without confirming which part was incorrect.
Implement Account Locking
- Temporarily lock accounts after a certain number of failed login attempts.
- Example: Lock an account for 10 minutes after 5 wrong attempts to prevent targeted brute-forcing.
Limit Login Attempts (Rate Limiting)
- Limit login attempts per IP address and block suspicious behavior.
- Example: Allow 5 attempts per minute per IP. Block further attempts for 15 minutes if the limit is exceeded.
Add CAPTCHA for Extra Protection
- Require users to complete a CAPTCHA after several failed login attempts.
- Example: After 3 failed logins, show a CAPTCHA like "Click all the images with traffic lights."
Implement Multi-Factor Authentication (MFA)
- Use app-based or hardware-based MFA instead of SMS.
- Example: After entering a password, require a 6-digit code from Google Authenticator or a similar app.
Secure Password Reset
- Use a time-limited, unique token for password reset links.
- Example: Send an email with a link that expires in 15 minutes. Ensure the link can only be used once.
Avoid SMS-Based MFA
- SMS 2FA can be bypassed via SIM-swapping attacks. Use app-based authentication instead.
- Example: Encourage users to set up an authenticator app for 2FA instead of relying on SMS codes.
Protect Additional Authentication Functions
- Secure features like account registration, password recovery, and password changes.
- Example: Require users to verify their email before changing their password.
Prevent Brute-Force Attacks on Multiple Accounts
- Limit the number of login attempts across all usernames using shortlists of passwords.
- Example: If an attacker tries common passwords like "123456" or "qwerty" across accounts, block them after 5 attempts.
Triple-Check Verification Logic
- Regularly audit login and authentication logic to prevent bypass vulnerabilities.
- Example: Ensure the system verifies both the username and password properly and doesn't skip steps due to flawed code.
Don’t Rely on Users for Security
- Enforce secure practices like strong passwords and MFA automatically.
- Example: Block weak passwords like "Password123" and require a unique, strong password.
Implement Robust Brute-Force Protections
- Require CAPTCHA or other verification methods after multiple failed attempts.
- Example: After 5 failed attempts from the same IP, show a CAPTCHA and notify the account owner.

Please feel free to add more :).

Acknowledgment: This document references information from PortSwigger Web Security

SQL Injection (SQLi)

Golam Mostafa — Thu, 26 Dec 2024 18:04:21 +0000

SQL Injection (SQLi) is a trick used by hackers to mess with websites. They add fake input into forms or URLs to access or steal data from a website's database.

How to Spot SQL Injection

Single Quotes (''): Enter a single quote (') in a form or URL. If you see an error, the website might be vulnerable.
Always True Condition: Try entering OR 1=1 (always true) or OR 1=2 (always false) and see if the site behaves differently.
Delays: Use commands like SLEEP(5) to see if the page takes longer to load.
External Calls: Test if your input makes the site connect to another server.

Example: Finding Hidden Items

For example:

https://example.com/products?category=Gifts

The site might use this command to get the products:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1;

This hides unreleased items (released = 1 shows only ready products).

What Hackers Do:

They can change the URL to:

https://example.com/products?category=Gifts'--

This changes the database query to:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1;

The -- ignores the rest of the query, showing all products, even hidden ones.

Example: Show Everything

Hackers can show all items, even unknown categories, by using:

https://example.com/products?category=Gifts'+OR+1=1--

This creates a query like:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1;

Since 1=1 is always true, the database returns everything.

Example: Hacking a Login

Think of a login form that checks username and password. Normally, it might do this:

SELECT * FROM users WHERE username = 'user' AND password = 'pass';

A hacker can enter this as the username:

user' OR '1'='1

The query becomes:

SELECT * FROM users WHERE username = 'user' OR '1'='1' AND password = 'pass';

Since 1=1 is always true, the hacker logs in without a password.

Be Careful

Testing SQLi is risky. Commands like OR 1=1 might delete or change important data if misused. Always handle websites and data responsibly.

To stay safe, websites must properly check user inputs and use secure coding practices.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

OWASP Top 10

Golam Mostafa — Mon, 16 Dec 2024 13:11:34 +0000

The OWASP Top 10 is a list of the most common and dangerous security risks for web applications. If you're building a website or an app, you need to know these risks to keep your system safe.

1. Broken Access Control (A01)

This happens when users can access things they shouldn’t, like admin pages or other users' data.

Example:

Imagine a normal user visiting:

https://example.com/admin

If they see admin pages, that’s broken access control.

How to Fix:

Use Authorization to check who can access what.
Add Role-Based Access Control (RBAC): e.g., Admin, User, Guest.
Use Secure Cookies.
Always validate inputs on the backend.

2. Cryptographic Failures (A02)

This happens when sensitive data like passwords or credit card info isn’t protected properly.

Example:

Storing passwords as plain text:

Password: mypassword123

If a hacker gets this, it’s game over.

How to Fix:

Use strong encryption for passwords like bcrypt.
Use HTTPS/TLS to secure data during transfer.
Example:

   const bcrypt = require('bcrypt');
   const hashedPassword = await bcrypt.hash("mypassword123", 10);
   console.log(hashedPassword);

3. Injection (A03)

This happens when a hacker sends harmful code (like SQL or scripts) into your application.

Example:

If your website takes input like this:

SELECT * FROM users WHERE id = 1;

A hacker could type:

1; DROP TABLE users;

How to Fix:

Validate and sanitize all inputs.
Use parameterized queries. Example in Node.js:

   const query = "SELECT * FROM users WHERE id = ?";
   db.query(query, [userId]);

4. Insecure Design (A04)

This happens when your system is not designed securely in the first place.

Example:

An app that allows weak passwords like "1234" is insecure by design.

How to Fix:

Use OWASP resources to follow secure design patterns.
Perform regular security reviews.

5. Security Misconfiguration (A05)

This happens when your app has default settings or unnecessary features enabled.

Example:

Leaving the default username and password:

admin / admin123

How to Fix:

Keep systems up-to-date.
Remove unused features and accounts.
Use safe error messages like "Invalid credentials" instead of exposing details.

6. Vulnerable and Outdated Components (A06)

This happens when your app uses old software or libraries with known security issues.

Example:

Using an old version of a library like express that has vulnerabilities.

How to Fix:

Update your libraries and software regularly.
Use security tools like npm audit to check for vulnerabilities.

7. Identification and Authentication Failures (A07)

This happens when attackers can bypass login systems.

Example:

Allowing weak passwords like "password123" or not locking accounts after failed logins.

How to Fix:

Use strong authentication like JWT tokens.
Store passwords securely.
Protect against brute-force attacks.
Example: Lock an account after 5 failed attempts.

8. Software and Data Integrity Failures (A08)

This happens when your software or data is tampered with during updates or transfers.

Example:

A hacker changes your app update to include malware.

How to Fix:

Always verify updates with digital signatures.
Use trusted sources for libraries.
Keep everything up-to-date.

9. Security Logging and Monitoring Failures (A09)

This happens when you don’t track suspicious activities on your app.

Example:

If someone tries to log in 100 times and fails, and you don’t log or monitor it, you might miss a brute-force attack.

How to Fix:

Add proper logging and monitoring.
Use tools like Winston or ELK Stack.
Example: Log failed login attempts:

   console.log(`Failed login attempt for user: ${username}`);

10. Server-Side Request Forgery (SSRF) (A10)

This happens when an attacker tricks your server into making a request to an internal system.

Example:

A hacker sends:

http://localhost/admin

If your app fetches this URL, it exposes internal data.

How to Fix:

Validate all URLs before making requests.
Don’t allow users to directly input URLs.
Example: Use a whitelist of trusted URLs.

Acknowledgment: This document references information from OWASP, Foyjul Karim and ChatGPT.

File Upload Vulnerabilities

Golam Mostafa — Sat, 23 Nov 2024 17:25:53 +0000

What Are File Upload Vulnerabilities?

File upload vulnerabilities occur when a server lets users upload files without proper checks. Attackers can exploit this to upload harmful files, like scripts, instead of safe ones, like images. Sometimes, just uploading the file causes damage; other times, attackers trigger the file to execute with a request.

How Do These Vulnerabilities Happen?

Even when protections exist, flaws in implementation can still allow attacks. Common issues include:

Blocking some dangerous file types but missing others.
Relying on file properties that attackers can fake using tools.
Inconsistent validation across the website.

These small mistakes give attackers ways to bypass security measures.

Exploiting Flawed File Upload Validation

Attackers often exploit weak validation to upload harmful scripts, like web shells. For example, a PHP script like this reads secret files:

<?php echo file_get_contents('secret.txt'); ?>

Or, a script like this can run system commands:

<?php echo system($_GET['cmd']); ?>

Attackers can send:

GET /hack.php?cmd=whoami

This shows the server's identity and gives attackers control.

Flawed File Type Validation

Some servers validate file uploads by checking the Content-Type header for expected MIME types like image/jpeg. However, if the server trusts this header without checking the file’s actual contents, attackers can easily bypass the validation.

For example, an image upload form may send this request:

POST /images HTTP/1.1  
Host: example.com  
Content-Type: multipart/form-data  

--boundary  
Content-Disposition: form-data; name="image"; filename="example.jpg"  
Content-Type: image/jpeg  

[binary data]  
--boundary--

If the server only verifies the Content-Type value, attackers can fake this using tools like Burp Repeater and upload malicious files disguised as images.

Protecting Against File Upload Vulnerabilities

To prevent these attacks:

Verify file content matches the declared type.
Store uploaded files in non-executable directories.
Use strict whitelists for allowed file types.
Scan files for malicious content.

Learn More: Watch the Tutorial

Acknowledgment: This post is inspired by insights from PortSwigger Web Security and ChatGPT.

SSRF Attacks: The Silent Threat Hiding in Your Server

Golam Mostafa — Sat, 16 Nov 2024 19:24:26 +0000

What is SSRF (Server-Side Request Forgery)?

Server-Side Request Forgery (SSRF) is a web vulnerability where attackers trick a server into making unauthorized requests to internal or external systems.

How Does It Work?

An attacker sends a malicious URL in a request that the server processes as legitimate. The server then makes the request on the attacker’s behalf.

Example:

A shopping app checks stock by making a backend API request:

POST /product/stock  
stockApi=http://stock.server.com/check?productId=6&storeId=1

An attacker modifies the URL to point to the server's admin page:

POST /product/stock  
stockApi=http://localhost/admin

The server fetches and returns restricted admin data, bypassing access controls.

Why Does This Happen?

Access Control Gaps: Checks are skipped for local requests.
Recovery Features: Admin access is granted to local users without authentication.
Hidden Interfaces: Admin tools on separate ports trust local machine requests.

Protect Against SSRF

Validate and sanitize input URLs.
Use URL whitelists.
Restrict internal service access.

SSRF can be critical, but good design and input validation can prevent it.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Weaknesses in Two-Factor Authentication

Golam Mostafa — Tue, 12 Nov 2024 19:54:40 +0000

Two-factor authentication (2FA) is meant to add extra security by asking for a password and then a code. However, some websites don’t fully enforce the second step.

For example, imagine logging in to a site that asks for your password, then moves to a page asking for a code. If the website considers you "logged in" after just the password, you might be able to skip the code and access secure pages.

To check if this flaw exists:

Enter your password.
When asked for the code, try going directly to a secure page.

If it works, the 2FA isn’t doing its job, and hackers could exploit this to bypass security.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Authentication vs. Authorization: Key Differences and Security Risks Explained

Golam Mostafa — Sat, 09 Nov 2024 15:14:21 +0000

When accessing online accounts or secure areas, two key security concepts play a role: Authentication and Authorization. Both are essential, but they serve different purposes. Let’s explore the differences with clear examples and highlight security risks, such as brute-force attacks and username enumeration, that threaten them.

What is Authentication?

Authentication is all about verifying identity. In simple terms, it’s how a system checks if you are really who you claim to be.

Example: Imagine Carlos tries logging into a website with the username “Carlos123.” Authentication is the process that checks if Carlos is indeed the person who created that account by verifying his password.

What is Authorization?

Authorization comes after authentication. Once the system knows who you are, authorization decides what you are allowed to do.

Example: After Carlos logs in, his account permissions determine what he can access. For instance, he might be authorized to view personal data but not to delete another user’s account.

Brute-Force Attacks

A brute-force attack is when an attacker tries different usernames and passwords repeatedly to gain access. Often, this is done with automated tools that test a vast number of login combinations very quickly.

How Brute-Forcing Works

Guessing Passwords: Attackers use common or predictable passwords, such as “Password123” or “Admin2023!” They might even try patterns based on the target, like adding “123” or “!” to simple words (e.g., “mypassword1!”).
Automated Tools: Tools like Hydra or Burp Suite make it easier to brute-force logins at high speed, increasing the chances of guessing correctly.

Example: Carlos uses “Carlos2023” as a password. An attacker using a brute-force tool could guess this password if it tries combinations based on his name.

Brute-Forcing Usernames

Usernames often follow patterns, making them easier to guess.

Example: Many companies use email addresses as usernames, like “firstname.lastname@company.com.” High-level accounts often use simple names like “admin” or “administrator,” which attackers know to try first.

Checking for Publicly Visible Usernames

Attackers can look for usernames on public pages. Sometimes websites unintentionally reveal usernames through profile links or in HTTP responses, providing attackers with information for brute-force attempts.

Brute-Forcing Passwords

While strong passwords are harder to guess, attackers know common tricks users apply to meet password requirements. For example, users might change “mypassword” to “Mypassword1!” to meet complexity rules. Attackers exploit these patterns by targeting predictable variations.

Example: If the original password “mypassword” is too weak, the user might create “Mypassword1!”. Attackers know these patterns, making brute-force attacks more efficient.

Username Enumeration

Username enumeration allows attackers to discover valid usernames by observing system responses.

How It Works

When entering a correct username with a wrong password, some sites give a different error message than for an incorrect username. This helps attackers confirm if a username exists, reducing the work needed to brute-force the password.

Example: If Carlos enters “Carlos123” with an incorrect password, the site might say, “Incorrect password,” rather than “Username not found.” This confirms to an attacker that “Carlos123” is a valid username.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Horizontal privilege escalation

Golam Mostafa — Mon, 28 Oct 2024 05:54:24 +0000

What is Horizontal Privilege Escalation?

Horizontal privilege escalation is when a user can see another user’s data that they shouldn’t have access to. For example, if you can view your account but change the URL to see someone else’s account, that’s a security problem called Insecure Direct Object Reference (IDOR).

Example of IDOR

Say your account page has this URL:

https://example.com/myaccount?id=123

If someone changes id=123 to a different number, they could accidentally see another user’s account. This happens because the website isn’t protecting users’ data properly.

How Some Sites Try to Prevent It

Websites sometimes use special codes, like long GUIDs instead of numbers, to make guessing harder. But even these codes can show up in other parts of the website, like messages or comments, where they can be misused.

Horizontal privilege escalation exposes private data and shows why websites need strong security controls to protect each user’s information.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.

Unprotected Functionality

Golam Mostafa — Tue, 22 Oct 2024 17:44:24 +0000

Title: Vertical Privilege Escalation

Vertical privilege escalation happens when regular users access admin-only areas due to weak access control and vice versa.

Example:

A user types example.com/admin. If there’s no restriction, they can access the admin panel without permission.

Key Points:

Direct URL Access: Typing sensitive URLs like /admin can bypass security.
robots.txt Exposure: Can accidentally reveal admin URLs.
Brute Force: Attackers guess URLs to find admin pages.

Dangers:

Unauthorized changes, data access, or system takeover.

Prevention:

Use strict role-based access controls.
Always secure sensitive areas, don’t rely on hidden URLs.

Title: The Flaw of Security by Obscurity

Hiding sensitive functionality behind a hard-to-guess URL isn’t true protection. This is known as "security by obscurity."

Example:

An admin URL like insecure-website.com/administrator-panel-yb556 might seem secure because it's not guessable. But if the URL is in the JavaScript, any user can inspect the code and find it.

Key Points:

Hidden URLs aren’t real security.
Visible in Code: Scripts or code can leak sensitive URLs to regular users.

Solution:

Always enforce strict access control; never rely on hiding URLs.

Acknowledgment: This document references information from PortSwigger Web Security and ChatGPT.