README

The DBStan package provides detailed analysis and insights into your database schema for Laravel applications. It helps identify structural issues, missing indexes, normalization problems, nullable column risks, foreign key inconsistencies, and performance concerns.

It is an essential tool for debugging, optimizing, reviewing, and maintaining a healthy database architecture in Laravel projects.

Important Notice: Configure Database Before Using This Package

Before using this package, ensure your database connection is properly configured in your Laravel application.

If the database is not configured correctly, DBStan will not be able to analyze your schema.

Make sure your .env file contains valid database credentials.

Security Warning

This package exposes detailed database schema analysis.
It is intended for admin and development use only.

Do NOT expose this tool publicly in production without proper access restrictions, as schema details may reveal sensitive structural information.

#Laravel  #Database  #Schema  #PHP  #Performance  #Optimization  #Analysis

Documentation

Features

• Analyze full database schema structure
• Detect missing indexes on foreign keys and log tables
• Identify nullable column overuse and high NULL value ratios
• Detect normalization and integrity issues (duplicate rows, orphan risks, improper foreign key naming)
• Audit trail checks (created_by, updated_by, deleted_by columns)
• Detect repeated common fields across tables
• Identify tables with too many columns or wide VARCHARs
• Highlight performance risks (large TEXT columns, JSON overuse, unbounded growth, table size)
• Detect improper pivot table structures
• Identify enum and boolean overuse
• Detect mixed domain columns (e.g., info/data/details in varchar)
• Check for missing soft deletes and timestamps
• Detect status columns missing indexes
• Detect polymorphic relation overuse and missing indexes
• Lightweight and optimized for fast schema scanning
• Supports Laravel 9, 10, and 11 with PHP 8+ compatibility
• CLI-based analysis with structured categorized output

Supported Versions

• PHP: ^8.0
• Illuminate Support: ^9.0 | ^10.0 | ^11.0

Installation

To install the package, run:

composer require itpathsolutions/dbstan

Commands

Vendor Publish (Optional)

After installing the package, you may publish the configuration file using:

php artisan vendor:publish --tag=dbstan-config

This will create the configuration file at:

config/dbstan.php

You can customize thresholds like:

• Maximum columns per table
• Maximum VARCHAR length
• JSON column limits
• Large table size threshold
• Nullable ratio threshold

Run Analysis for Production

To analyze your database schema:

php artisan dbstan:analyze

or

http://127.0.0.1:8000/dbstan

These both scans your entire database and displays categorized results in the browser or terminal.

Export Report

Currently, DBStan displays analysis results in the terminal or browser.

Future versions may support exporting reports to JSON, HTML, or PDF formats.

Output Categories

DBStan organizes its findings into four main categories:

1. Structure Issues

• Tables with too many columns
• Wide VARCHAR fields
• Missing timestamps or soft deletes
• Boolean and enum overuse
• Nullable column overuse
• Large TEXT columns
• Data type appropriateness
• Mixed domain columns
• Repeated common fields across tables
• Pivot table structure issues

2. Integrity Issues

• Duplicate rows detection
• Foreign key naming inconsistencies
• Cascading action problems
• Possible orphan risks
• Unique constraint violations

3. Performance Issues

• Missing indexes on foreign keys
• Missing indexes on log tables
• Missing indexes on status columns
• High NULL value ratios
• Table size analysis
• Unbounded growth risks

4. Architecture Issues

• Audit trail implementation (created_by, updated_by, deleted_by)
• JSON column overuse
• Polymorphic relation overuse

Environment Configuration

Ensure your .env file contains:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_database
DB_USERNAME=your_username
DB_PASSWORD=your_password

After updating configuration:

php artisan config:clear

FAQs

1. What does this package do?

DBStan analyzes your Laravel database schema and detects structural, normalization, and performance issues.

2. Does it modify my database?

No. DBStan is completely read-only.
It does NOT make any changes to your database.

3. Is it safe for production?

Yes, but it is recommended to use it in development or staging environments.
Avoid exposing schema analysis publicly.

Contributing

Contributions are welcome!

If you’d like to contribute:

1. Fork the repository
2. Create a feature branch (git checkout -b feature/your-feature)
3. Commit your changes (git commit -am 'Add new feature')
4. Push to the branch (git push origin feature/your-feature)
5. Open a Pull Request

Please ensure:

• Your code follows PSR-12 coding standards
• All tests pass before submitting
• You include tests for new features

For major changes, please open an issue first to discuss what you would like to change.

Security Vulnerabilities

If you discover a security vulnerability within DBStan, please send an email to enquiry@itpathsolutions.com.

All security vulnerabilities will be promptly addressed.

For more details, see our Security Policy.

License

DBStan is open-sourced software licensed under the MIT license.

A couple of months ago, Eindhoven-based designer Paul Staal was thinking about a new project: a smart dashboard for his home office. His idea was to integrate the dashboard into a 3D-printed shell that paid homage to Lego’s classic 2×2 sloped computer brick, a piece that’ll be instantly recognizable to anyone who has spent any time with vintage Space Lego sets.

Eventually, Staal tells Gizmodo, he decided to combine the dashboard into a case for his Mac Mini: “[I thought], ‘Why would I add another device to my desk? Why not just make it large enough for my [computer] instead?’”

The original design stuck closely to that of the Lego brick, but Staal found the result “bland and boring”: without the detailing on the front of the brick, the case was essentially just a large right-angled triangle. But then inspiration struck: why not combine the Lego silhouette with the aesthetics of another 1980s design icon?

The result was the M2x2, a case that takes its inspiration from both Lego’s classic console brick and the original Apple Macintosh. It’s 3D printed with a filament that’s an absolute dead ringer for the latter’s beige plastic shell, and equipped with a 7” touch screen, multiple USB-C ports, an SD card reader, and a handle for portability.

The design is full of clever touches: for example, the two large studs atop the case are both functional, with one serving as a volume knob for Staal’s Bluetooth speaker and the other as a wireless charger for his AirPods and Apple Watch. (They’re also adorned with actual Lego studs that can accommodate a mini-figure—or, indeed, one of the bricks that served as the design’s inspiration.) Anyone else using the design can customize the functionality to their liking: “I made the design for this case modular,” Staal explains, “so if anyone wants to make one, they can choose what they want to use the studs for.”

The touchscreen, meanwhile, is essentially self-contained: “It offer[s] quick access to some controls on my Home Assistant dashboard.” Staal says that if he makes another version of the device, he’d perhaps replace it with an iPad Mini to take advantage of that device’s integration with macOS. “Maybe I’ll work on that in the future,” he says, “perhaps even pairing it with a Mac Studio instead of a Mac mini.”

For now, though, he has a couple of other projects on the go: “I have a couple of other projects that I still want to document/finalise and share on my website… One of them is a new dock for my Nintendo Switch 2, [which] I hope to finish somewhere in the upcoming weeks, so stay tuned.”

MySQL Security Best Practices: A Practical Guide for Locking Down Your Database

Introduction

MySQL runs just about everywhere. I’ve seen it behind small personal projects, internal tools, SaaS platforms, and large enterprise systems handling serious transaction volume. When your database sits at the center of everything, it becomes part of your security perimeter whether you planned it that way or not. And that makes it a target.

Securing MySQL isn’t about flipping one magical setting and calling it done. It’s about layers. Tight access control. Encrypted connections. Clear visibility into what’s happening on the server. And operational discipline that doesn’t drift over time.

In this guide, I’m going to walk through practical MySQL security best practices that you can apply right away. These are the kinds of checks and hardening steps that reduce real risk in real environments, and help build a database platform that stays resilient under pressure.

1. Principle of Least Privilege

One of the most common security mistakes is over-granting privileges.
Applications and users should have only the permissions they absolutely
need.

Bad Practice

GRANT ALL PRIVILEGES ON *.* TO 'appuser'@'10.%';

Better Approach

GRANT SELECT, INSERT, UPDATE ON appdb.* TO 'appuser'@'10.%';

Recommendations

• Avoid global privileges unless absolutely required
• Restrict users by host whenever possible
• Separate admin accounts from application accounts
• Use different credentials for read-only vs write operations

Audit Existing Privileges

SELECT user, host, Select_priv, Insert_priv, Update_priv, Delete_priv
FROM mysql.user;

2. Strong Authentication & Password Policies

Weak credentials remain one of the easiest attack vectors.

Enable Password Validation

component_validate_password is MySQL’s modern password policy engine. Think of it as a gatekeeper for credential quality. Every time someone tries to set or change a password, it checks whether that password meets your defined security standards before letting it in.

It replaces the older validate_password plugin with a component-based architecture that is more flexible and better aligned with MySQL 8.x design.

INSTALL COMPONENT 'file://component_validate_password';

What It Does

When enabled, it enforces rules such as:

• Minimum password length
• Required mix of character types
• Dictionary file checks
• Strength scoring

If a password fails policy, the statement is rejected before the credential is stored.

Why It Matters

Weak passwords remain one of the most common entry points in database breaches. This component reduces risk by enforcing baseline credential hygiene automatically, instead of relying on developer discipline.

Recommended Policies

• Minimum length: 14+ characters
• Require mixed case, numbers, and symbols
• Enable dictionary checks
• Enable username checks

Remove Anonymous Accounts

Find Anonymous Users

Anonymous users have an empty User field.

SELECT user, host FROM mysql.user WHERE user='';

If you see rows returned, those are anonymous accounts.

Drop Anonymous Users

In modern MySQL versions:

DROP USER ''@'localhost';
DROP USER ''@'%';

Adjust the Host value based on what your query returned.

Why This Matters

Anonymous users:

• Allow login without credentials
• May have default privileges in some distributions
• Increase the attack surface unnecessarily

In hardened environments, there should be zero accounts with an empty username. Every identity should be explicit, accountable, and least-privileged.

3. Encryption Everywhere

Encryption protects data both in transit and at rest.

Enable Transparent Data Encryption (TDE)

See my January 13 post for a deep dive into Transparent Data Encryption:
Configuring the Component Keyring in Percona Server and PXC 8.4

Enable TLS for Connections

require_secure_transport=ON

Verify SSL Usage

SHOW STATUS LIKE 'Ssl_cipher';

Encryption Areas to Consider

• Client-server connections
• Replication channels
• Backups and snapshot storage
• Disk-level encryption

4. Patch Management & Version Hygiene

Running outdated MySQL versions is equivalent to leaving known
vulnerabilities exposed.

Maintenance Strategy

• Track vendor security advisories
• Apply minor updates regularly
• Test patches in staging before production rollout
• Avoid unsupported MySQL versions

Check Version

5. Logging, Auditing, and Monitoring

Security without visibility is blind defense, enable Audit Logging.

1. audit_log Plugin (Legacy Model)

Installation

INSTALL PLUGIN audit_log SONAME 'audit_log.so';

Verify

SHOW PLUGINS LIKE 'audit%';

2. audit_log_filter Component (Modern Model)

Introduced in MySQL 8 to provide a more flexible and granular alternative to the older plugin model.

Installation

INSTALL COMPONENT 'file://component_audit_log_filter';

Verify

SELECT * FROM mysql.component;

Architecture Difference

Instead of a single global policy, you create:

• Filters (define what to log)
• Users assigned to filters

It’s granular and rule-driven.

Auditing Key Events

• Failed logins
• Privilege changes
• Schema modifications
• Unusual query activity

References:

1. Audit Log Filter Component
2. Audit Log Filters Part II

Useful Metrics

SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Connections';

6. Secure Configuration Hardening

A secure baseline configuration reduces risk from common attack
patterns.

Recommended Settings

local_infile=OFF
secure_file_priv=/var/lib/mysql-files
sql_mode="STRICT_ALL_TABLES"
secure-log-path=/var/log/mysql

Why These Matter

• Prevent arbitrary file imports
• Reduce filesystem abuse
• Restrict data export/import locations

7. Backup Security

Backups often contain everything an attacker wants.

Backup Best Practices

• Encrypt backups
• Restrict filesystem permissions
• Store offsite copies securely
• Rotate backup credentials
• Verify restore procedures regularly

Example Permission Check

8. Replication & Cluster Security

Replication is not just a data distribution feature. It is a persistent, privileged communication channel between servers. If misconfigured, it can become a lateral movement pathway inside your infrastructure. Treat every replication link as a trusted but tightly controlled corridor.

Principle: Replication Is a Privileged Service Account

Replication users require elevated capabilities. They must be isolated, tightly scoped, and monitored like any other service identity.

Secure Replication Users

CREATE USER 'repl'@'10.%'
 IDENTIFIED BY 'strongpassword'
 REQUIRE SSL;

GRANT REPLICATION REPLICA ON *.* TO 'repl'@'10.%';

Hardening considerations:

• Restrict host patterns as narrowly as possible. Avoid % whenever feasible.
• Require SSL or X.509 certificate authentication.
• Enforce strong password policies or use a secrets manager.
• Disable interactive login capability if applicable.

Encrypt Replication Traffic

Replication traffic may include sensitive row data, DDL statements, and metadata. Always encrypt it.

At minimum:

• Enable require_secure_transport=ON
• Configure TLS certificates on source and replica
• Set replication channel to use SSL:

CHANGE REPLICATION SOURCE TO
 SOURCE_SSL=1,
 SOURCE_SSL_CA='/path/ca.pem',
 SOURCE_SSL_CERT='/path/client-cert.pem',
 SOURCE_SSL_KEY='/path/client-key.pem';

For MySQL Group Replication or InnoDB Cluster:

• Enable group communication SSL
• Validate certificate identity
• Use dedicated replication networks

Binary Log and Relay Log Protection

Replication relies on binary logs. Protect them.

• Set binlog_encryption=ON
• Set relay_log_info_repository=TABLE
• Restrict filesystem access to log directories
• Monitor log retention policies

Compromised binary logs can reveal historical data changes.

9. Continuous Security Reviews

Security is not a one-time checklist. Regular audits help catch
configuration drift and evolving threats.

Suggested Review Cadence

• Weekly: failed login review
• Monthly: privilege audits
• Quarterly: configuration review
• Semiannually: full security assessment

Security Checklist Summary

Final Thoughts

Strong MySQL security doesn’t come from one feature or one tool. It comes from layers working together. Hardened configuration. Tight, intentional privilege design. Encryption everywhere it makes sense. And monitoring that actually gets reviewed instead of just written to disk.

In my experience, the strongest environments aren’t the ones trying to be unbreakable. They’re the ones built to detect, contain, and respond. Every layer should either reduce blast radius or increase visibility. If an attacker gets through one control, the next one slows them down. And while they’re slowing down, your logging and monitoring should already be telling you something isn’t right.

That’s what a mature security posture looks like in practice. ∎

After three years of development and extensive production use, Workflow 3.0 brings significant improvements to building multi-step procedures in PHP. This release focuses on simplifying asynchronous execution, improving developer experience, and adding essential resilience features.

# Dependency injection

Version 3.0 introduces container support for injecting dependencies into jobs at runtime:

This enables workflows to remain stateless while accessing services like databases or HTTP clients through the container.

# Callable support

Version 3.0 accepts any PHP callable as a job, providing flexibility in how you define workflow steps:

This eliminates boilerplate for simple operations while maintaining support for Action classes when business logic requires full class structure. Callables enable inline data transformation without requiring dedicated action classes for single-use operations.

# Response property access

Version 3.0 extends response() to access public object properties directly, not just array keys:

This works transparently with both arrays and objects, allowing actions to return domain objects without requiring array conversion. The workflow engine inspects the response and accesses properties or array keys accordingly.

# Retry policies

Transient failures in distributed systems are inevitable. Workflow 3.0 implements configurable retry policies:

Retry policies are essential for handling transient failures in distributed systems, where network operations and external services may temporarily fail but succeed on subsequent attempts.

# True async execution

The parallel runner has been replaced with a true async implementation using AMPHP. This provides non-blocking execution without the overhead of process forking, leveraging PHP 8.1+ Fibers for efficient multitasking.

Independent jobs execute concurrently while the engine manages the resolution of the dependency graph. This follows asynchronous task-based execution model where the scheduler unrolls the graph and executes nodes as soon as their data dependencies (like response()) are satisfied. This shift significantly reduces memory footprint compared to the previous process-based model while maintaining strict execution order.

# Conditional execution

Version 3.0 adds withRunIfNot() for cleaner conditional logic:

This complements withRunIf() and accepts boolean literals, variables, job responses, and callables. Conditional execution enables branching without complex orchestration logic.

# Type safety

Integration with chevere/parameter 2.0 provides runtime validation:

Workflow validates inputs before job execution and verifies response types match expected parameters in dependent jobs. This eliminates a class of runtime errors that would otherwise require extensive testing.

# Practical example

Here’s a complete workflow for processing user uploads:

This workflow validates the file, resizes and optimizes it in parallel, then stores the result. The resize job retries on failure, and both processing jobs only run if validation succeeds.

# Migration notes

The parallel runner removal is the only breaking change. Applications using parallel execution should switch to async jobs with appropriate dependency declarations. The async runner provides better performance and simpler semantics.

# Conclusion

Workflow 3.0 represents three years of production refinement. The addition of container support, callables, retry policies, and true async execution address real-world requirements while maintaining the declarative approach that makes workflows maintainable.

The library continues following established patterns from workflow research and distributed systems literature. Each job remains independently testable, workflows stay declarative, and the dependency graph handles execution ordering automatically.

For complete documentation and examples, visit chevere.org/packages/workflow.