DEV Community: Lee

One-Line Defense Against BOLA: Killing Data-Level if-else Hell with PHP-Casbin

Lee — Thu, 10 Sep 2026 16:13:18 +0000

In web application security, Broken Object Level Authorization (BOLA, or IDOR) consistently haunts the top ranks of the OWASP API Security Top 10.

To put it in plain English: Alice logs into your app, views her invoice at /orders/1001, and then notices the number in her browser address bar. She casually changes 1001 to 1002, hits Enter, and suddenly she is staring at Bob's private shipping address and billing details. If your API is even sloppier, she might fire off a DELETE request and wipe out Charlie's data entirely.

Most teams initially fight this vulnerability by littering their controllers with defensive if-else checks. But as the product evolves, business code gets buried under layers of hotfixes—fix one leak here, accidentally open three new ones over there.

Here is the good news: PHP-Casbin natively supports passing full PHP objects directly into its enforcement engine. With a single line of code, you can shut down object-level authorization bypasses for good.

The Pain of Hardcoded Ownership Checks

Take a look at the all-too-familiar spaghetti code in controllers without a dedicated authorization engine:

// An everyday ownership check inside a controller
public function update(Request $request, int $orderId)
{
    $order = Order::findOrFail($orderId);
    $user = auth()->user();

    // Business rules and permission checks tangled together
    if ($user->role !== 'admin' && $order->owner_id !== $user->id) {
        throw new ForbiddenException("Hands off someone else's order!");
    }
    if ($order->status === 'archived' && $user->role !== 'admin') {
        throw new BusinessException("Archived orders cannot be modified.");
    }

    $order->update($request->validated());
}

This brute-force approach seems easy enough on day one, but it quickly turns into a maintenance nightmare:

Leaks everywhere: Updating an order needs an ownership check, viewing details needs one, downloading attachments needs one, canceling needs another. You end up copy-pasting the same snippet across dozens of endpoints. The moment a newcomer forgets that check on a new route, you have a critical security vulnerability in production.
Modifying rules feels like walking through a minefield: The product manager suddenly asks: "Can quality assurance leads temporarily edit orders during business hours?" You now have to hunt down every single related controller and append new conditions to those if statements, praying you did not miss one.
Permission clutter overshadows business logic: The core purpose of your method is simply updating a few fields, yet half the code is occupied with detective work verifying who owns what.

Busting the Myth: Casbin Only Takes Strings?

Many developers who have dabbled in Casbin remember it looking something like this:

// The classic route-level interception
$enforcer->enforce('alice', '/api/orders', 'POST');

This leaves an unfortunate misconception: people assume Casbin only accepts plain strings, works exclusively at the gateway or middleware layer, and can only answer questions like "Can this user call this route?" When it comes to "Can this user edit this specific record?", many believe Casbin cannot help.

That could not be further from the truth. The PERM metamodel behind Casbin is remarkably expressive. In PHP-Casbin, enforce() can take real PHP objects directly. While evaluating the matcher expression, the engine dynamically reaches into the object, inspects its properties, and performs the check on the fly.

Rule Configuration: Decoupling Policy from Code

All you need is a concise abac_model.conf file to declare your ownership rules and business constraints in one clean place:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub.role == "admin" || (r.sub.id == r.obj.owner_id && r.act in ["read", "update"] && r.obj.status != "archived")

The configuration is brief, and the logic is straightforward:

r.sub represents the subject (the requester). You can pass the authenticated user object directly; the engine will automatically resolve r.sub.id and r.sub.role.
r.obj represents the target resource. You pass the retrieved order model directly; the engine compares r.obj.owner_id and checks r.obj.status.
m serves as the referee: system administrators get an immediate green light; regular users must satisfy two strict conditions—they must own the data, and the order must not be archived.

In the Controller: Keeping Business Logic Clean

With the policy declared externally, your controller code suddenly becomes a breath of fresh air:

use Casbin\Enforcer;

class OrderController
{
    public function update(Request $request, int $orderId, Enforcer $enforcer)
    {
        $order = Order::findOrFail($orderId);
        $user = auth()->user();

        // One clean line: pass the user, the resource, and the action to Casbin
        if (!$enforcer->enforce($user, $order, 'update')) {
            abort(403, "You do not have permission to modify this record.");
        }

        // Clean, uncluttered business execution
        $order->update($request->validated());
        return response()->json(['message' => 'Updated successfully']);
    }
}

The controller no longer cares about the intricate relationship between users, roles, and resource states. It merely hands the user and the data model over to the enforcer. If it receives false, it returns a 403.

If product requirements change tomorrow—say, giving support supervisors temporary edit access—you only need to adjust the matcher in your configuration file. Not a single line of your controller code needs to be touched.

Native Compatibility with Real-World PHP Objects

You might wonder: "My project uses Laravel Eloquent with dynamic attributes via __get(), and my teammate prefers strongly-typed DTOs. Can Casbin handle that?"

The answer is yes. PHP-Casbin comes with adaptive introspection built in:

// Plain DTOs, stdClass instances, or Eloquent models all work out of the box
$user = auth()->user();
$order = Order::findOrFail($orderId);

// The engine transparently resolves public properties, getters, and magic attributes
$enforcer->enforce($user, $order, 'update');

Whether you pass standard PHP entities, dynamic data objects, or framework models with magic getters, the engine resolves the requested fields effortlessly. There is zero need to flatten objects into arrays or serialize them to JSON beforehand. Just pass the objects as they are.

Wrapping Up

If access control stops at route-level checks, it is like a security guard who checks IDs at the building's front entrance while leaving every apartment door wide open.

Stop cluttering your business logic with defensive, error-prone ownership checks. By leveraging object-level ABAC in PHP-Casbin, you can extract permission rules into a clean declarative model. You will shut down BOLA vulnerabilities before they hit production, and you will save your team countless hours of frustrating bug-hunting down the road.

Mastering Cryptography in Go: Introducing `go-think/openssl`

Lee — Fri, 21 Aug 2026 04:13:30 +0000

Zero-Boilerplate, 100% Cross-Language Compatible Encryption for Go Developers

Cryptography in Go has always been a tale of two worlds.

On one hand, Go's standard library crypto/* packages are well-crafted, secure, and fast. On the other hand, implementing everyday cryptographic workflows—like encrypting a payload with AES-CBC (PKCS#7), performing AES-ECB for legacy systems, or handling RSA encryption for large payloads—requires writing dozens of lines of repetitive boilerplate code.

Even worse, subtle differences in padding schemes, IV handlings, or key truncations often lead to frustrating cross-language decryption failures when communicating with PHP (openssl_encrypt), Java (javax.crypto), Python (pycryptodome), or Node.js.

To solve these headaches once and for all, meet go-think/openssl — a developer-friendly, pure Go cryptographic toolkit that brings simplicity and seamless cross-platform interoperability to Go applications.

💡 Why `go-think/openssl`?

Pure Go, No CGO Dependencies: Lightweight, cross-compilation friendly, and built on top of standard Go crypto primitives.
Zero-Boilerplate API: Do what used to take 40 lines in just 2 or 3 lines.
100% Cross-Language Compatibility: Produces identical binary ciphertext to OpenSSL, PHP, Java, Python, and Node.js.
Smart Padding & Chunking:
- Native support for PKCS#7 (PKCS#5) and ZeroPadding.
- Automatic chunking for RSA encryption and decryption of arbitrarily long messages.
Batteries Included: AES, DES, 3DES, RSA, MD5, SHA-1 to SHA-512, and HMAC.

🚀 Quick Installation

go get -u github.com/go-think/openssl

🛠️ Code in Action

1. Symmetric Encryption: AES (CBC, ECB & GCM)

Standard Go requires manual block padding, block mode initialization, and slice slicing. With go-think/openssl, it is as simple as:

AES-CBC with PKCS#7 Padding

package main

import (
    "encoding/base64"
    "fmt"
    "github.com/go-think/openssl"
)

func main() {
    src := []byte("Hello, Cross-Language World!")
    key := []byte("1234567890123456") // 16-byte key for AES-128
    iv  := []byte("1234567890123456") // 16-byte IV

    // Encrypt
    cipherText, err := openssl.AesCBCEncrypt(src, key, iv, openssl.PKCS7_PADDING)
    if err != nil {
        panic(err)
    }
    fmt.Println("Base64 Ciphertext:", base64.StdEncoding.EncodeToString(cipherText))

    // Decrypt
    plainText, err := openssl.AesCBCDecrypt(cipherText, key, iv, openssl.PKCS7_PADDING)
    if err != nil {
        panic(err)
    }
    fmt.Println("Decrypted:", string(plainText))
}

Modern AEAD: AES-GCM (Authenticated Encryption)

For applications that require authenticated encryption with integrity checks:

nonce := []byte("123456789012")          // 12-byte standard nonce
aad   := []byte("authenticated_header") // Additional authenticated data

// Encrypt
dst, err := openssl.AesGCMEncrypt(src, key, nonce, aad)

// Decrypt
plain, err := openssl.AesGCMDecrypt(dst, key, nonce, aad)

Also supports CFB, OFB, CTR, as well as legacy DES and 3DES ciphers out of the box.

2. Painless RSA: Key Generation, Signatures & Auto-Chunking

One notorious limitation of raw RSA is that it cannot encrypt data larger than its key size minus padding overhead. Usually, developers must write chunking and buffer reassembly logic. go-think/openssl handles this automatically:

package main

import (
    "bytes"
    "crypto"
    "fmt"
    "github.com/go-think/openssl"
)

func main() {
    // 1. Generate a 2048-bit RSA Key Pair in PEM format
    var privBuf, pubBuf bytes.Buffer
    _ = openssl.RSAGenerateKey(2048, &privBuf)
    _ = openssl.RSAGeneratePublicKey(privBuf.Bytes(), &pubBuf)

    privKey := privBuf.Bytes()
    pubKey  := pubBuf.Bytes()

    // 2. Encrypt arbitrary-length data (Automatic chunking under the hood)
    longData := []byte("A very long message that exceeds standard RSA block size limit...")
    encrypted, _ := openssl.RSAEncrypt(longData, pubKey)

    // Decrypt
    decrypted, _ := openssl.RSADecrypt(encrypted, privKey)
    fmt.Println("Decrypted RSA:", string(decrypted))

    // 3. Digital Signatures (RSASign & RSAVerify)
    signature, _ := openssl.RSASign(longData, privKey, crypto.SHA256)

    err := openssl.RSAVerify(longData, signature, pubKey, crypto.SHA256)
    if err == nil {
        fmt.Println("Signature verified successfully!")
    }
}

Note: RSAEncrypt also seamlessly accepts X.509 CERTIFICATE PEM blocks!

3. One-Liner Hashes & HMACs

Stop creating hash.Hash interfaces just to get a hex digest:

// MD5
hexMD5 := openssl.Md5ToString("hello world")

// SHA-256
hexSHA := openssl.Sha256ToString("hello world")

// HMAC-SHA256
hmacStr := openssl.HmacSha256ToString("secret-key", "hello world")

🌐 100% Interoperability: Go vs. PHP vs. Java

Let's test if the ciphertext generated by Go matches other platforms bit-for-bit.

In Go (`go-think/openssl`):

src := []byte("123456")
key := []byte("1234567890123456")
iv  := []byte("1234567890123456")

dst, _ := openssl.AesCBCEncrypt(src, key, iv, openssl.PKCS7_PADDING)
fmt.Println(base64.StdEncoding.EncodeToString(dst))
// Output: 1jdzWuniG6UMtoa3T6uNLA==

In PHP (`openssl_encrypt`):

<?php
$data = "123456";
$key  = "1234567890123456";
$iv   = "1234567890123456";

$encrypted = openssl_encrypt($data, 'aes-128-cbc', $key, OPENSSL_RAW_DATA, $iv);
echo base64_encode($encrypted);
// Output: 1jdzWuniG6UMtoa3T6uNLA== (Identical!)

In Java (`javax.crypto`):

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key.getBytes(), "AES"), new IvParameterSpec(iv.getBytes()));
byte[] encrypted = cipher.doFinal(data.getBytes(StandardCharsets.UTF_8));
System.out.println(Base64.getEncoder().encodeToString(encrypted));
// Output: 1jdzWuniG6UMtoa3T6uNLA== (Identical!)

📦 Summary

If you are building Go microservices that need to interact with external APIs, legacy systems, mobile apps, or other backends without wrestling with cryptographic discrepancies, go-think/openssl will save you hours of debugging.

GitHub Repository: https://github.com/go-think/openssl
Go Package Documentation: pkg.go.dev/github.com/go-think/openssl
License: Apache 2.0

Give it a ⭐ on GitHub if you find it useful, and feel free to submit issues or pull requests!

Yii-Permission 3.0 Released: Built for Yii 3.0

Lee — Fri, 31 Jul 2026 02:56:27 +0000

In modern web development and enterprise system architecture, a flexible and efficient access control system is the ultimate cornerstone of application security. As a powerful and high-performance open-source access control framework, Casbin supports various access control models—including ACL, RBAC, and ABAC—and is widely adopted across multiple language ecosystems.

As the official Casbin extension for the PHP Yii framework, php-casbin/yii-permission officially launched its major v3.0.0 release on July 30, 2026.

Embracing Yii 3.0's Standalone Component Ecosystem

The core highlight of v3.0 lies in its full adaptation to the Yii 3.0 framework architecture. As Yii 3.0 transitions toward a modernized, highly componentized, and PSR-standard-compliant design, yii-permission has undergone a complete architectural redesign—from low-level design to interface integration:

Higher Minimum Environment Requirements: The package now requires PHP 8.2+, taking full advantage of the latest type system and strong typing to boost code robustness.
Modern DI Container Configuration: Upgraded configuration management powered by yiisoft/config ensures that declaring and initializing the Casbin authorization engine aligns seamlessly with Yii 3.0 native standards.

Complete Decoupling: From Traditional Components to PSR-15 Middleware

In the Yii 2.0 era, access control was largely dependent on controller-level behaviors or Application components. Following modern PHP web architecture trends, yii-permission 3.0 introduces PSR-15 standard HTTP middleware:

EnforcerMiddleware: Intercepts requests directly within the HTTP pipeline to execute Casbin model-based authorization.
RequestMiddleware: Facilitates context preprocessing and extraction from incoming requests.

With PSR-15 middleware, authorization logic can be effortlessly attached to global request pipelines or specific route groups, significantly improving middleware reusability and execution efficiency.

Seamless Integration with Yiisoft Access Interface

To deliver a consistent developer experience for Yii users, yii-permission 3.0 introduces a new AccessChecker class implementing the Yiisoft\Access\AccessCheckerInterface.

This allows developers to continue using Yii's native access-checking semantics:

// Easily perform permission checks in controllers or services using the unified interface
if ($user->can('article.update', ['article' => $article])) {
    // Permission granted: perform update operation
}

Under the hood, authorization decisions are driven by Casbin's high-performance engine, while the application layer stays fully aligned with Yii standards—dramatically lowering the learning curve for project migrations and secondary development.

Key Updates Summary

According to the official GitHub Release notes, here is a summary of the key features and breaking changes in v3.0.0:

Yii 3.0 Compatibility: Full support for Yii 3.0's standalone component ecosystem and Dependency Injection (DI) standards.
Updated Requirements: Requires PHP 8.2 or higher and Yii 3.0 framework packages.
PSR-15 Middleware Architecture: Introduced EnforcerMiddleware and RequestMiddleware to replace legacy controller components.
Native AccessChecker Support: Added the AccessChecker class implementing Yiisoft\Access\AccessCheckerInterface, seamlessly empowering $user->can().
Configuration & CI Optimization: Integrated yiisoft/config for DI configuration management; updated GitHub Actions CI workflows, PHP testing matrices, and code coverage configurations.

Recommendation & Upgrade Advice

If you are building a new project with PHP 8.2+ and Yii 3.0, or planning to upgrade an existing application to Yii 3’s modern component stack, php-casbin/yii-permission 3.0 is the premier access control solution.

Whether you need simple RBAC for single-tenant systems, or complex, multi-tenant ABAC (Attribute-Based Access Control) for high-concurrency environments, it provides a clean, standardized, and high-performance security layer.

GitHub Repository: https://github.com/php-casbin/yii-permission