DEV Community: Vicky [TrixCyrus]

50 Essential Linux Commands Every Developer Should Know in 2026

Vicky [TrixCyrus] — Tue, 18 Aug 2026 09:42:45 +0000

Author: Vicky Builds

50 Essential Linux Commands Every Developer Should Know in 2026

Linux remains the backbone of modern development, powering everything from cloud servers to embedded systems. Whether you're deploying applications, managing containers, or automating workflows, mastering the command line is non-negotiable. This guide covers 50 essential Linux commands—from basics to advanced—with practical examples for developers in 2026.

File Operations
Directory Navigation
System Monitoring
Networking
Package Management
Process Management
File Permissions
Text Processing
Archiving & Compression
Advanced Tools

File Operations

1. `ls` – List Files

List files and directories in the current folder.

ls          # Basic list
ls -l       # Detailed list (permissions, owner, size)
ls -a       # Show hidden files (dotfiles)
ls -lh      # Human-readable file sizes (KB, MB, GB)

2. `cat` – Display File Content

Print the contents of a file to the terminal.

cat file.txt

3. `touch` – Create Empty Files

Create one or more empty files.

touch newfile.txt

4. `rm` – Remove Files/Directories

Delete files or directories permanently (use with caution!).

rm file.txt          # Delete a file
rm -r directory/     # Delete a directory recursively
rm -f file.txt       # Force delete (no confirmation)
rm -i file.txt       # Prompt before deleting

5. `cp` – Copy Files/Directories

Copy files or directories from one location to another.

cp file.txt /path/to/destination/      # Copy a file
cp -r directory/ /path/to/destination/ # Copy a directory recursively

6. `mv` – Move/Rename Files

Move files or rename them.

mv oldname.txt newname.txt   # Rename a file
mv file.txt /path/to/destination/   # Move a file

7. `find` – Search for Files

Search for files by name, type, or modification time.

find /path -name "*.txt"       # Find all .txt files
find /path -type f -mtime -7    # Find files modified in the last 7 days
find /path -size +10M           # Find files larger than 10MB

8. `grep` – Search Text Patterns

Search for text patterns within files.

grep "error" logfile.txt       # Search for "error" in a file
grep -r "pattern" /path/      # Recursively search in directories
grep -i "pattern" file.txt    # Case-insensitive search

9. `head` / `tail` – View File Snippets

View the beginning or end of a file.

head -n 10 file.txt   # Show first 10 lines
tail -n 10 file.txt   # Show last 10 lines
tail -f logfile.txt  # Follow (live update) a log file

10. `wc` – Count Words, Lines, Characters

Count lines, words, and characters in a file.

wc file.txt          # Line, word, and character count
wc -l file.txt       # Only line count
wc -w file.txt       # Only word count

Directory Navigation

11. `pwd` – Print Working Directory

Display the current directory path.

pwd

12. `cd` – Change Directory

Navigate between directories.

cd /path/to/directory   # Change to a specific directory
cd ~                   # Go to home directory
cd ..                  # Move up one directory
cd -                   # Return to previous directory

13. `mkdir` – Create Directories

Create new directories.

mkdir newdir          # Create a single directory
mkdir -p parent/child # Create nested directories

14. `rmdir` – Remove Empty Directories

Delete empty directories.

rmdir empty_dir/       # Remove an empty directory

15. `tree` – Display Directory Structure

Show a tree-like structure of directories and files.

tree                 # Show current directory structure
tree -L 2            # Limit depth to 2 levels

System Monitoring

16. `top` / `htop` – Monitor Processes

View real-time system processes, CPU, and memory usage.

top    # Basic process viewer (pre-installed)
htop  # Enhanced version (install with `sudo apt install htop`)

17. `df` – Disk Space Usage

Check disk space usage for all mounted filesystems.

df -h   # Human-readable format (KB, MB, GB)

18. `du` – Directory Space Usage

Estimate file and directory space usage.

du -sh /path/to/directory   # Summary of directory size
du -h --max-depth=1          # Size of subdirectories (1 level deep)

19. `free` – Memory Usage

Display memory (RAM) and swap usage.

free -h   # Human-readable format

20. `uptime` – System Uptime

Show how long the system has been running.

uptime

Networking

21. `ping` – Test Network Connectivity

Check connectivity to a server or website.

ping google.com

22. `curl` – Transfer Data via URLs

Download files or interact with APIs.

curl https://example.com          # Fetch webpage content
curl -O https://example.com/file.zip  # Download a file

23. `wget` – Download Files

Download files from the web.

wget https://example.com/file.zip

24. `ifconfig` / `ip` – Network Interfaces

View network interface configurations.

ifconfig       # Older systems
ip a           # Modern replacement

25. `netstat` / `ss` – Network Statistics

Display network connections, routing tables, and interface statistics.

netstat -tuln   # List listening ports (TCP/UDP)
ss -tuln       # Modern replacement

Package Management

26. `apt` (Debian/Ubuntu) – Package Manager

Install, update, and remove packages.

sudo apt update          # Update package lists
sudo apt upgrade         # Upgrade installed packages
sudo apt install nginx   # Install a package
sudo apt remove nginx    # Remove a package

27. `yum` (RHEL/CentOS) / `dnf` (Fedora)

sudo yum install nginx   # RHEL/CentOS
sudo dnf install nginx   # Fedora

28. `snap` – Universal Package Manager

Install snaps (containerized software packages).

sudo snap install spotify

29. `flatpak` – Sandboxed Applications

Install and run sandboxed apps.

flatpak install flathub com.spotify.Client

Process Management

30. `ps` – List Running Processes

View active processes.

ps aux          # List all processes
ps -ef | grep nginx  # Filter processes by name

31. `kill` – Terminate Processes

Stop a process by its PID.

kill 1234       # Gracefully terminate process ID 1234
kill -9 1234    # Forcefully kill process

32. `pkill` – Kill Processes by Name

Terminate processes by name.

pkill nginx      # Kill all processes named "nginx"

33. `bg` / `fg` – Background/Foreground Jobs

Manage background and foreground jobs.

ctrl + Z   # Suspend a process
bg        # Resume suspended job in the background
fg        # Bring job to the foreground

34. `jobs` – List Background Jobs

View currently running background jobs.

jobs

File Permissions

35. `chmod` – Change File Permissions

Modify file permissions (read, write, execute).

chmod 755 script.sh   # Give owner rwx, others rx
chmod +x script.sh    # Make file executable

36. `chown` – Change Ownership

Change the owner and group of a file/directory.

sudo chown user:group file.txt

37. `umask` – Set Default Permissions

Define default permissions for new files.

umask 022   # Default permissions for new files (755 for dirs, 644 for files)

Text Processing

38. `sed` – Stream Editor

Edit text streams (find/replace).

sed 's/old/new/g' file.txt   # Replace "old" with "new" globally

39. `awk` – Pattern Scanning

Process structured text (e.g., logs, CSV).

awk '{print $1}' file.txt   # Print first column

40. `sort` – Sort Lines

Sort lines in a file.

sort file.txt          # Sort alphabetically
sort -n file.txt       # Sort numerically
sort -r file.txt       # Reverse order

41. `uniq` – Remove Duplicate Lines

Filter duplicate lines (often used with sort).

sort file.txt | uniq   # Sort and remove duplicates

42. `cut` – Extract Sections from Files

Extract specific columns or fields.

cut -d',' -f1 file.csv   # Extract first column (comma-delimited)

Archiving & Compression

43. `tar` – Archive Files

Create or extract .tar archives.

tar -cvf archive.tar /path/to/files   # Create archive
tar -xvf archive.tar                  # Extract archive
tar -czvf archive.tar.gz /path/      # Compress with gzip

44. `gzip` / `gunzip` – Compress/Decompress

Compress or decompress .gz files.

gzip file.txt      # Compress
gunzip file.txt.gz # Decompress

45. `zip` / `unzip` – ZIP Archives

Create or extract .zip files.

zip archive.zip file1 file2   # Create ZIP
unzip archive.zip             # Extract ZIP

Advanced Tools

46. `cron` – Schedule Tasks

Automate commands at specific times.

crontab -e   # Edit cron jobs
# Example: Run script daily at 3 AM
0 3 * * * /path/to/script.sh

47. `rsync` – Remote File Sync

Sync files/directories locally or over SSH.

rsync -avz source/ user@remote:/destination/

48. `ssh` – Secure Shell

Connect to remote machines securely.

ssh user@hostname   # Connect to a remote server
ssh -p 2222 user@hostname  # Custom port

49. `scp` – Secure Copy

Copy files over SSH.

scp file.txt user@remote:/path/to/destination

50. `tmux` – Terminal Multiplexer

Manage multiple terminal sessions.

tmux new -s mysession   # Start a new session
tmux ls                 # List sessions
tmux attach -t mysession # Reattach to a session

Bonus: Aliases for Efficiency

Add these to your ~/.bashrc or ~/.zshrc to save time:

# Shortcuts
alias ll='ls -alF'
alias la='ls -A'
alias gs='git status'
alias ga='git add'
alias gc='git commit -m'

# Safety nets
alias rm='rm -i'      # Prompt before deletion
alias cp='cp -i'      # Prompt before overwrite
alias mv='mv -i'      # Prompt before overwrite

Final Tips

Use man for Help: man command (e.g., man ls) displays the manual page.
Tab Completion: Press Tab to auto-complete commands/paths.
History: Use history to view past commands and !n to repeat command #n.
Pipes (|): Chain commands (e.g., cat file.txt | grep "error").
Redirects: Save output to a file with > (overwrite) or >> (append).

   ls -l > filelist.txt

Why Master These Commands?

Cloud & DevOps: Essential for managing servers (AWS, GCP, Azure).
Containers: Docker, Kubernetes, and CI/CD pipelines rely on Linux.
Automation: Scripting repetitive tasks saves hours.
Debugging: Logs, processes, and network tools are indispensable.

What’s your go-to Linux command? Share in the comments!

~vickybuilds

Linux vs Unix: Which Should You Choose for Development in 2026?

Vicky [TrixCyrus] — Mon, 17 Aug 2026 05:01:47 +0000

Author: Vicky

[🔹 Profile] vickybuilds on Dev.to

Linux vs Unix: Which Should You Choose for Development in 2026?

The debate between Linux and Unix isn't just historical—it's a practical decision that developers still face today. While Linux dominates cloud infrastructure and open-source ecosystems, Unix and its modern derivatives (like macOS and BSD) remain critical in enterprise, embedded systems, and high-reliability environments.

If you're deciding which platform to standardize on for your next project, understanding the real differences—beyond the "open vs. proprietary" soundbite—is essential. This article breaks down what matters in 2026: tooling, ecosystem, performance, and long-term viability.

The Historical Divide

Unix: The Foundation

Unix originated in 1969 at AT&T's Bell Labs, created by Dennis Ritchie and Ken Thompson as a portable, multi-user OS. Its design philosophy—simple, modular tools that do one thing well—became the bedrock of modern computing. By the 1970s and 80s, Unix fragmented into commercial variants (AIX, HP-UX, Solaris) and academic branches (BSD), each with proprietary modifications.

Linux: The Open-Source Revolution

In 1991, Linus Torvalds released the Linux kernel under the GPL, creating the first truly open-source Unix-like OS. Unlike Unix, Linux was never controlled by a single vendor. Instead, it evolved through community collaboration, with distributions like Debian, Fedora, and Ubuntu packaging the kernel with GNU tools to form complete operating systems.

Key Milestone: By 2026, Linux powers over 70% of cloud servers, 100% of the world's top 500 supercomputers, and the vast majority of embedded devices. Unix, meanwhile, persists in legacy enterprise systems, macOS (a certified Unix), and BSD variants like FreeBSD.

Architecture and Design

Kernel

Unix: Monolithic kernel architecture (though some variants like macOS use hybrid models). The kernel and user space are tightly integrated, which can limit flexibility but enhances stability.
Linux: Monolithic with loadable kernel modules (LKMs). This allows dynamic addition/removal of drivers and features without recompiling the kernel—a critical advantage for development and hardware support.

Filesystem Hierarchy

Both follow the Filesystem Hierarchy Standard (FHS) to some degree, but differences exist:

Feature	Unix (Traditional)	Linux
`/usr` vs `/`	Often merged	Typically separate
`/opt`	Common for add‑ons	Standard
`/home`	Not always present	Standard for user dirs
Case Sensitivity	Always case‑sensitive	Always case‑sensitive

2026 Note: Modern Unix‑like systems (macOS, FreeBSD) have converged closer to Linux's FHS for compatibility.

Licensing and Cost

Unix: Proprietary Roots

Commercial Unix (AIX, HP‑UX, Solaris): Requires paid licenses, often tied to specific hardware. Support contracts are mandatory for updates.
BSD (FreeBSD, OpenBSD, NetBSD): Permissive BSD license. Free to use, modify, and redistribute, even in proprietary software.
macOS: Unix‑certified (Single UNIX Specification), but closed‑source and Apple‑controlled.

Linux: Open Source Dominance

GPLv2 License: The Linux kernel is free to use, modify, and distribute, but derivatives must also be open‑sourced (copyleft).
Distributions:
- Community (Debian, Fedora, Arch): Free, community‑supported.
- Enterprise (RHEL, SUSE, Ubuntu LTS): Free to download, but paid support/subscriptions for updates and security patches.
- No Vendor Lock‑in: You can switch distributions or fork the code without legal restrictions.

2026 Reality Check:

Unix: Only viable if you're locked into legacy enterprise hardware or macOS for development.
Linux: The de‑facto standard for new projects, with zero licensing costs for most use cases.

Development Ecosystem

Package Management

System	Unix (AIX/HP‑UX)	macOS	FreeBSD	Linux (Debian)	Linux (RHEL)
Package Manager	`smit` (AIX), `swinstall` (HP‑UX)	`brew`, `port`	`pkg`, `ports`	`apt`, `dpkg`	`yum`, `dnf`, `rpm`
Repositories	Vendor‑controlled	Homebrew, MacPorts	Official + community	~60k packages	EPEL, RPM Fusion
Binary Compatibility	Limited	Good (x86_64, ARM)	Good	Excellent	Excellent

Winner for Developers: Linux. The sheer volume of pre‑built packages, language runtimes, and development tools in repositories like Debian's or Fedora's is unmatched. Even macOS, while Unix‑certified, relies heavily on Homebrew—which is essentially a Linux‑style package manager.

Tooling and Compatibility

POSIX Compliance: Both are POSIX‑compliant, meaning most shell scripts and C programs written for one will work on the other with minimal changes.
GNU Tools: Linux distributions include GNU coreutils (grep, sed, awk, etc.), which often have more features than their Unix counterparts.
Development Stacks:
- Python, Node.js, Go, Rust: All have first‑class support on Linux. Unix systems may require manual compilation or lack the latest versions.
- Containers: Docker, Podman, and Kubernetes are Linux‑first. While Docker runs on macOS (via a Linux VM), native Unix support is limited.
- Cloud‑Native Tools: kubectl, terraform, helm—all assume a Linux environment.

2026 Trend: The rise of WebAssembly (WASM) and containerization further cements Linux as the target platform. Even Unix vendors now offer Linux compatibility layers (e.g., IBM's AIX Toolbox for Linux Applications).

Performance and Stability

Unix: The Stability Benchmark

Uptime: Commercial Unix systems (AIX, Solaris) are renowned for extreme stability, often running for years without rebooting.
Hardware Optimization: Tuned for specific hardware (e.g., IBM Power, SPARC), offering predictable performance.
Resource Usage: Generally heavier due to proprietary optimizations and legacy code.

Linux: The Performance Powerhouse

Customization: Can be stripped down to the bare essentials (e.g., Alpine Linux, minimal Docker containers).
Hardware Support: Works on everything from Raspberry Pi to mainframes. The 6.8+ kernel (2026) includes optimizations for ARM, RISC‑V, and x86_64.
Real‑Time Capabilities: The PREEMPT_RT patchset enables real‑time performance for latency‑sensitive applications (robotics, audio processing).

Benchmark Example (2026):

Web Server (Nginx): Linux on x86_64 outperforms Unix on equivalent hardware by ~15‑20% in requests/second (TechEmpower benchmarks).
Database (PostgreSQL): Unix (Solaris) edges out Linux in raw throughput for OLTP workloads, but Linux wins in scalability and horizontal partitioning.

Verdict: For most workloads, Linux is faster and more scalable. Unix excels in niche, high‑reliability scenarios.

Use Cases in 2026

Choose Unix If:

Legacy Enterprise Systems: Running mission‑critical applications on AIX, HP‑UX, or Solaris with vendor support.
macOS Development: Building iOS/macOS apps (Xcode requires macOS).
BSD for Networking: FreeBSD is the OS of choice for high‑performance networking (pfSense, Netgate routers).
Certification Requirements: Some industries (finance, aerospace) mandate Unix for compliance.

Choose Linux If:

Cloud‑Native Development: Building microservices, containers, or serverless functions (AWS, GCP, Azure all run Linux).
Open‑Source Projects: Contributing to or using open‑source tools (99% are Linux‑first).
Embedded/IoT: Linux (Yocto, Buildroot) dominates embedded systems, from smart TVs to industrial controllers.
Data Science/AI: TensorFlow, PyTorch, and CUDA have first‑class Linux support. Unix support is often an afterthought.
Cost Sensitivity: Avoiding licensing fees for servers or development workstations.

2026 Market Share (Stack Overflow Developer Survey):

Server OS: Linux (72%), Windows (18%), Unix (5%), macOS (3%), BSD (2%)
Development OS: macOS (45%), Linux (35%), Windows (20%)

Which Should You Choose? A Decision Framework

Factor	Unix (Commercial)	Unix (BSD/macOS)	Linux
Cost	High (licenses)	Low (macOS: hardware cost)	Free
Hardware Support	Limited (vendor‑specific)	Good (Apple Silicon, x86)	Excellent (x86, ARM, RISC‑V, etc.)
Package Ecosystem	Poor (vendor‑controlled)	Good (Homebrew)	Excellent (apt, yum, dnf, etc.)
Cloud‑Native Tools	Limited	Partial (Docker via VM)	Full Support
Stability	Excellent	Good	Good (improving with each kernel release)
Performance	Excellent (niche)	Good	Excellent (scalable)
Community Support	Vendor‑only	Good (BSD), Excellent (macOS)	Excellent
Learning Curve	Steep (proprietary tools)	Moderate	Moderate (but vast documentation)
Future‑Proofing	Declining	Stable (macOS), Stable (BSD)	Growing

Recommendations:

For Most Developers: Linux (Ubuntu LTS or Fedora) is the clear winner. It's free, has the best tooling, and aligns with modern development practices.
For macOS Users: Stick with macOS if you're building Apple ecosystem apps. Otherwise, consider dual‑booting Linux or using a VM for non‑macOS development.
For Enterprise Legacy: If you're maintaining AIX/HP‑UX/Solaris systems, Unix is non‑negotiable. Start planning a migration to Linux.
For Networking/Embedded: FreeBSD for networking, Linux for embedded.
For Learning: Linux. The skills transfer to Unix, but not vice versa.

Practical Next Steps

If You Choose Linux:

Pick a Distribution:
- Beginners: Ubuntu LTS or Linux Mint
- Developers: Fedora or Debian Testing
- Enterprise: RHEL or SUSE
- Minimalist: Arch Linux or Alpine
Set Up Your Environment:

   # Install essential tools on Debian/Ubuntu
   sudo apt update && sudo apt install -y \
     git curl wget build-essential \
     python3 python3-pip nodejs npm \
     docker.io podman

Learn the Basics:
- Filesystem navigation (cd, ls, find)
- Package management (apt, dnf, yum)
- Process management (systemctl, ps, kill)
- Text processing (grep, sed, awk)

If You Choose Unix (macOS/BSD):

On macOS:
- Install Homebrew: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
- Use brew for packages: brew install git node python
On FreeBSD:
- Use pkg for packages: pkg install git node python
- Compile from ports if needed: cd /usr/ports/lang/python && make install

The Future: What's Next?

Unix in 2026 and Beyond

Declining but Not Dead: Commercial Unix (AIX, HP‑UX) is in maintenance mode. IBM and Oracle still support these, but new features are rare.
macOS: Apple's shift to ARM (Apple Silicon) has revitalized Unix on the desktop. macOS Ventura and later include improved Linux compatibility (e.g., better Docker support).
BSD: FreeBSD 14 (2026) focuses on cloud and container support, bridging the gap with Linux.

Linux in 2026 and Beyond

Kernel 6.x: Continued improvements in performance, security (e.g., memory safety with Rust in the kernel), and hardware support.
Immutable Distributions: Fedora Silverblue, Vanilla OS, and others are gaining traction for reproducible development environments.
WASM Integration: Linux is at the forefront of WebAssembly adoption, enabling portable, high‑performance applications.
AI/ML Dominance: Linux is the OS of choice for AI workloads, with NVIDIA, AMD, and Intel optimizing drivers and libraries for it.

Prediction: By 2030, Unix will be a niche player (macOS for Apple development, BSD for networking, legacy enterprise). Linux will dominate servers, cloud, embedded, and even desktops (thanks to SteamOS, ChromeOS, and improved UI/UX in distros like Pop!_OS).

Conclusion

The choice between Linux and Unix in 2026 isn't about which is better—it's about which aligns with your goals.

Choose Unix (or macOS/BSD) if you're tied to legacy systems, Apple's ecosystem, or need the extreme stability of commercial Unix.
Choose Linux for everything else. It's the platform of the future, with unmatched tooling, community support, and alignment with modern development practices.

For most developers, the answer is clear: Linux is the pragmatic choice. But understanding Unix's legacy and where it still excels will make you a more well‑rounded engineer—and help you appreciate why Linux became the dominant force it is today.

What's your experience with Linux vs Unix? Share your thoughts in the comments below.

~vickybuilds

Google Dorking in 2026: The Ultimate Guide for Security Researchers

Vicky [TrixCyrus] — Wed, 15 Jul 2026 13:51:43 +0000

Author: Vicky [Trix Cyrus]

Waymap Pentesting tool: Click Here
TrixSec Github: Click Here
TrixSec Telegram: Click Here

What if I told you that one of the most powerful reconnaissance tools available to a security researcher is something you probably use every single day?

Google.

Google indexes billions of web pages, documents, directories, login portals, APIs, error messages, and other publicly accessible resources.

Normally, we search Google using simple keywords.

But security researchers can take advantage of advanced search operators to perform much more targeted searches.

This technique is commonly known as:

Google Dorking or Google Hacking

In this guide, we'll explore Google Dorking in 2026, from basic search operators to practical reconnaissance techniques that security researchers, penetration testers, bug bounty hunters, and OSINT investigators can use during authorized assessments.

We'll also look at how defenders can discover what information about their own infrastructure has been indexed by search engines.

⚠️ Disclaimer

This article is intended strictly for educational purposes, OSINT research, defensive security, and authorized penetration testing. Only perform security testing against systems you own or have explicit permission to test.

Finding a page through Google does not give you authorization to exploit or access it.

What Is Google Dorking?

Google Dorking is the practice of using advanced Google Search operators to locate specific information indexed by Google's search engine.

A normal Google search might look like:

cybersecurity tools

A Google Dork might look like:

site:example.com filetype:pdf

This tells Google:

Show me PDF files indexed from example.com.

We can make the search even more specific:

site:example.com filetype:pdf "security"

Now we're asking Google to find PDF documents associated with a particular keyword.

Google Dorking is therefore not some magical vulnerability scanner.

At its core, it is advanced search-engine reconnaissance.

The power comes from combining multiple operators to filter Google's massive index.

Why Security Researchers Use Google Dorks

Google Dorking can be useful during the reconnaissance phase of an authorized security assessment.

Researchers may use advanced searches to identify:

Publicly indexed documents
Forgotten web pages
Development documentation
API documentation
Login portals
Public directories
Legacy applications
Error messages
Technology references
Indexed subdomains
Public configuration examples
Exposed metadata

In many cases, the interesting information isn't necessarily a vulnerability.

Instead, it becomes another piece of the reconnaissance puzzle.

Essential Google Dork Operators

Before getting into security-specific searches, let's understand the operators.

1. `site:`

The site: operator restricts results to a particular domain.

site:example.com

This displays pages Google has indexed from that domain.

You can also search for specific content:

site:example.com security

For reconnaissance, this is often one of the first operators researchers use.

2. `inurl:`

The inurl: operator searches for specific text appearing inside URLs.

inurl:docs

For an authorized target:

site:example.com inurl:docs

This may help identify URLs containing docs.

Other examples:

site:example.com inurl:api

site:example.com inurl:developer

site:example.com inurl:login

3. `intitle:`

This searches for specific words appearing in page titles.

intitle:"documentation"

Combined with a target domain:

site:example.com intitle:"documentation"

Another example:

site:example.com intitle:"login"

This can be useful when mapping publicly indexed application interfaces.

4. `intext:`

The intext: operator searches for text appearing within the content of a webpage.

intext:"API documentation"

For example:

site:example.com intext:"API documentation"

This can help locate technical documentation or references.

5. `filetype:`

This is one of the most useful operators for OSINT.

filetype:pdf

You can combine it with a domain:

site:example.com filetype:pdf

Other interesting file formats include:

filetype:doc
filetype:docx
filetype:xls
filetype:xlsx
filetype:csv
filetype:txt
filetype:xml
filetype:json
filetype:ppt
filetype:pptx

Organizations often publish documents without realizing how much information those documents can reveal.

6. Exact Search `"..."`

Quotation marks search for an exact phrase.

"penetration testing"

This becomes powerful when combined with other operators:

site:example.com "API documentation"

Or:

site:example.com "internal documentation"

7. Excluding Results with `-`

The minus operator removes unwanted results.

For example:

site:example.com -www

This may help reduce results from the primary website while searching for other indexed hosts.

You can also exclude keywords:

site:example.com filetype:pdf -marketing

8. `OR`

The OR operator allows multiple search conditions.

"security research" OR "penetration testing"

Combined with a domain:

site:example.com ("security" OR "cybersecurity")

Practical Google Dorks for Security Research

Now let's combine these operators into useful reconnaissance categories.

Always replace example.com with a domain that you are authorized to assess.

1. Domain Reconnaissance

Start simple.

site:example.com

This provides a quick overview of indexed pages associated with the domain.

To reduce results from the primary host:

site:example.com -www

You might discover references to hosts such as:

blog.example.com
docs.example.com
support.example.com
developer.example.com

Google is not a complete subdomain-enumeration tool, but it can complement:

Certificate Transparency searches
DNS enumeration
Passive DNS
Internet archives
Dedicated reconnaissance tools

2. Finding Login Pages

During an authorized security assessment, identifying authentication surfaces can be useful.

site:example.com inurl:login

site:example.com intitle:"login"

site:example.com inurl:signin

site:example.com intitle:"sign in"

Finding a login page does not mean the page is vulnerable.

However, authentication interfaces are important assets that organizations should track and protect.

3. Finding Publicly Indexed Documents

Documents can provide valuable OSINT.

site:example.com filetype:pdf

site:example.com filetype:docx

site:example.com filetype:xlsx

site:example.com filetype:pptx

site:example.com filetype:csv

During an authorized assessment, these searches can help identify documents that may have been unintentionally made public.

Documents can sometimes expose metadata such as:

Employee names
Usernames
Internal project names
Software versions
Operating systems
Document authors
Organizational structures
Internal naming conventions

This is why metadata analysis remains an important part of OSINT.

4. Finding Documentation

Documentation can reveal how applications and services are structured.

Try:

site:example.com inurl:docs

site:example.com intitle:"documentation"

site:example.com "developer documentation"

site:example.com "technical documentation"

Public documentation might reveal information about:

APIs
SDKs
Authentication methods
Application architecture
Integrations
Legacy services

Remember: publicly discovering documentation does not automatically authorize testing the systems described by it.

5. Discovering API References

Modern applications rely heavily on APIs.

Researchers assessing their own infrastructure might search:

site:example.com inurl:api

site:example.com "API documentation"

site:example.com inurl:developer

site:example.com "API reference"

These searches may reveal developer portals and publicly documented APIs.

From a defensive perspective, this is useful for answering an important question:

Do we know about every API that is publicly associated with our organization?

6. Finding Directory Listings

Misconfigured web servers can sometimes expose directory indexes.

During an authorized assessment, researchers may search for indexing patterns such as:

site:example.com intitle:"index of"

You can narrow this to your own infrastructure:

site:example.com intitle:"index of" "parent directory"

Directory listings are not automatically vulnerabilities.

However, unintended directory indexing can reveal files that were never meant to be easily discoverable.

7. Finding Error Messages

Error messages can provide information about the technologies running behind an application.

A defensive researcher might search their domain for indexed error pages:

site:example.com "error"

Or look for technology-specific diagnostic messages associated with systems they own.

Why does this matter?

Verbose errors can sometimes reveal:

Framework names
Database technologies
Internal file paths
Application structure
Software versions

Production systems should generally avoid exposing unnecessary debugging information.

8. Discovering Technology References

Google can also help identify technologies associated with a domain.

For example:

site:example.com "WordPress"

site:example.com "Laravel"

site:example.com "Django"

site:example.com "Next.js"

site:example.com "React"

These results should not be treated as definitive fingerprinting.

However, they can provide clues that can later be validated using authorized reconnaissance techniques.

9. Finding Public Configuration Documentation

Security teams can search their own domains for configuration-related content.

For example:

site:example.com "configuration"

site:example.com "config"

site:example.com filetype:txt "configuration"

The goal here is not to hunt for other organizations' secrets.

The goal is to answer:

Has our organization accidentally published information that should not be publicly indexed?

If sensitive configuration data is publicly accessible, the correct response is to remove the exposure and rotate any affected credentials or secrets.

10. SQL Injection Reconnaissance

Historically, Google Dork lists often contained thousands of URL patterns such as:

product.php?id=

news.php?id=

index.php?page=

detail.php?id=

product.php?product_id=

The idea was simple.

Dynamic parameters could indicate pages where user-controlled input was passed to backend application logic.

However, this is important:

A URL containing ?id= is NOT evidence of SQL injection.

Modern applications may use parameterized queries, ORMs, validation, prepared statements, and other protections.

During an authorized assessment, Google can help identify indexed parameterized URLs:

site:example.com inurl:"?id="

Or patterns relevant to the application you're testing:

site:example.com inurl:"product.php?id="

These are reconnaissance queries, not vulnerability confirmations.

Any further testing should only happen within an explicitly authorized scope.

11. Finding Legacy Application Patterns

Old applications are often forgotten.

Security teams can use Google to search their own domains for older technologies or URL structures.

For example:

site:example.com inurl:.php

site:example.com inurl:.asp

site:example.com inurl:.aspx

This doesn't mean these technologies are inherently insecure.

The purpose is asset discovery.

An old application that nobody remembers maintaining can become a security risk if it stops receiving updates.

12. Finding Development Resources

Development resources sometimes become publicly indexed.

Researchers can search authorized domains using:

site:example.com inurl:dev

site:example.com inurl:developer

site:example.com inurl:docs

site:example.com "development"

These queries can help organizations identify development-related resources visible from the public internet.

Again, discovery does not equal vulnerability.

13. Combining Google Dorks

The real power of Google Dorking comes from combining operators.

Instead of:

site:example.com

Try:

site:example.com filetype:pdf

Then narrow it further:

site:example.com filetype:pdf "security"

Or:

site:example.com inurl:docs intitle:"API"

Or:

site:example.com filetype:xlsx -www

Think of Google Dorking as creating increasingly precise filters.

A good reconnaissance strategy is:

Broad Search
    ↓
Identify Interesting Results
    ↓
Add Operators
    ↓
Reduce Noise
    ↓
Validate Findings

Don't start with an enormous query.

Start broad and progressively narrow your search.

A Practical Google Dorking Workflow

Here's a structured workflow you can use when assessing a domain you own or have authorization to test.

Phase 1 — Map the Domain

site:example.com

Identify indexed pages and publicly visible sections.

Phase 2 — Look Beyond the Main Site

site:example.com -www

Review other indexed hosts and services.

Phase 3 — Search Documents

site:example.com filetype:pdf

site:example.com filetype:docx

site:example.com filetype:xlsx

Review whether any publicly accessible documents expose unnecessary information.

Phase 4 — Find Documentation

site:example.com inurl:docs

site:example.com intitle:"documentation"

Phase 5 — Identify APIs

site:example.com inurl:api

site:example.com "API documentation"

Phase 6 — Inventory Authentication Surfaces

site:example.com inurl:login

site:example.com intitle:"login"

Phase 7 — Look for Indexed Error Pages

Search your own domain for known application or framework error messages.

Review whether production systems are exposing unnecessary technical details.

Phase 8 — Investigate Findings

Google Dorking should be treated as a discovery mechanism.

Interesting findings should then be:

Validated
Added to the asset inventory
Checked against the authorized testing scope
Investigated using appropriate security tools

Google Dorking + Other Recon Techniques

Google Dorking becomes much more powerful when combined with other reconnaissance methods.

A modern reconnaissance workflow might include:

Search Engine Intelligence

Discover publicly indexed resources.

Certificate Transparency

Identify certificates and associated subdomains.

DNS Enumeration

Discover additional infrastructure.

Internet Archives

Investigate historical versions of websites.

Public Code Repositories

Identify publicly available source code and documentation.

Technology Fingerprinting

Understand the technologies exposed by authorized targets.

Vulnerability Scanning

Test authorized infrastructure for known security issues.

Each technique reveals a different part of the attack surface.

Automating Google Dorking

At scale, manually searching hundreds of queries becomes inefficient.

However, blindly automating Google searches can violate search-engine terms or trigger rate limiting.

A better approach for security teams is to build a structured reconnaissance pipeline using approved APIs and passive data sources.

For example:

Target Domain
     │
     ├── Search Engine Recon
     │
     ├── DNS Enumeration
     │
     ├── Certificate Transparency
     │
     ├── Archive Analysis
     │
     ├── URL Collection
     │
     └── Technology Detection
              │
              ▼
        Asset Inventory
              │
              ▼
      Authorized Security Testing

This turns random "dorking" into a repeatable attack-surface management process.

Google Dorking vs Vulnerability Scanning

These two techniques are often confused.

Google Dorking is primarily:

Discovery and reconnaissance.

Vulnerability scanning is:

Testing identified systems for security weaknesses.

For example:

Google Dorking
      ↓
Discover Application
      ↓
Confirm Asset Ownership
      ↓
Verify Testing Authorization
      ↓
Run Security Assessment
      ↓
Validate Findings
      ↓
Report Vulnerabilities

The authorization step is critical.

How Organizations Can Protect Themselves

Google Dorking is useful not only for attackers and penetration testers.

Blue teams can use the same techniques defensively.

Organizations should periodically search their own domains to understand what search engines have indexed.

1. Audit Your Search-Engine Exposure

Start with:

site:yourcompany.com

Look for unexpected pages, documents, and services.

2. Never Use `robots.txt` as Access Control

A common misconception is that adding a page to robots.txt makes it private.

It doesn't.

robots.txt provides instructions to compliant crawlers.

It is not an authentication system.

Sensitive resources should be protected using proper access controls.

3. Remove Sensitive Public Files

Do not store confidential documents in publicly accessible web directories.

If sensitive information has already been exposed:

Remove the file
Request removal from search indexes where appropriate
Rotate exposed credentials
Investigate access logs
Determine the impact

4. Disable Unnecessary Directory Listings

Directory listings should be disabled unless they are intentionally required.

5. Remove Debug Information

Production applications should not expose verbose debugging information.

Errors should be logged securely on the server rather than displaying unnecessary technical details to users.

6. Maintain an External Asset Inventory

You cannot secure infrastructure you don't know exists.

Track:

Domains
Subdomains
APIs
Cloud services
Development environments
Staging environments
Authentication portals
Legacy applications

Then continuously compare your known inventory with externally discoverable assets.

Is Google Dorking Still Relevant in 2026?

Absolutely.

But the way security researchers should think about it has changed.

Google Dorking should not simply be:

"Copy 10,000 random dorks and search the internet."

A better approach is:

"Use advanced search techniques to understand the publicly visible attack surface of systems you're authorized to assess."

Modern reconnaissance combines:

Google Dorking
        +
OSINT
        +
DNS Intelligence
        +
Certificate Transparency
        +
Historical URLs
        +
Asset Discovery
        +
Security Scanning

Together, these techniques can provide a much clearer picture of an organization's external attack surface.

Final Thoughts

Google Dorking remains one of the simplest ways to understand how much information search engines know about a website.

You don't need an expensive tool to get started.

Sometimes all you need is:

site:

inurl:

intitle:

intext:

filetype:

And the ability to combine them intelligently.

For security researchers, the real skill isn't memorizing thousands of Google Dorks.

It's understanding what you're looking for, why you're looking for it, and how that information fits into a larger reconnaissance process.

If you're learning cybersecurity, try these techniques against your own website or an intentionally vulnerable lab environment.

You might be surprised by how much information has already been indexed.

Reference

This article was inspired in part by Benji Trapp's collection of Google Dorks and historical SQL-related URL patterns:

Google Dorks List & SQLi List

Use Google Dorking responsibly and only perform security testing where you have explicit authorization.

If you found this guide useful, consider leaving a reaction and sharing it with other security researchers.

More cybersecurity, penetration testing, OSINT, Python, and open-source security content coming soon.

~Trixsec

DEV Community: Vicky [TrixCyrus]

50 Essential Linux Commands Every Developer Should Know in 2026

50 Essential Linux Commands Every Developer Should Know in 2026

Table of Contents

File Operations

1. ls – List Files

2. cat – Display File Content

3. touch – Create Empty Files

4. rm – Remove Files/Directories

5. cp – Copy Files/Directories

6. mv – Move/Rename Files

7. find – Search for Files

8. grep – Search Text Patterns

9. head / tail – View File Snippets

10. wc – Count Words, Lines, Characters

Directory Navigation

11. pwd – Print Working Directory

12. cd – Change Directory

13. mkdir – Create Directories

14. rmdir – Remove Empty Directories

15. tree – Display Directory Structure

System Monitoring

16. top / htop – Monitor Processes

17. df – Disk Space Usage

18. du – Directory Space Usage

19. free – Memory Usage

20. uptime – System Uptime

Networking

21. ping – Test Network Connectivity

22. curl – Transfer Data via URLs

23. wget – Download Files

24. ifconfig / ip – Network Interfaces

25. netstat / ss – Network Statistics

Package Management

26. apt (Debian/Ubuntu) – Package Manager

27. yum (RHEL/CentOS) / dnf (Fedora)

28. snap – Universal Package Manager

29. flatpak – Sandboxed Applications

Process Management

30. ps – List Running Processes

31. kill – Terminate Processes

32. pkill – Kill Processes by Name

33. bg / fg – Background/Foreground Jobs

34. jobs – List Background Jobs

File Permissions

35. chmod – Change File Permissions

36. chown – Change Ownership

37. umask – Set Default Permissions

Text Processing

38. sed – Stream Editor

39. awk – Pattern Scanning

40. sort – Sort Lines

41. uniq – Remove Duplicate Lines

42. cut – Extract Sections from Files

Archiving & Compression

43. tar – Archive Files

44. gzip / gunzip – Compress/Decompress

45. zip / unzip – ZIP Archives

Advanced Tools

46. cron – Schedule Tasks

47. rsync – Remote File Sync

48. ssh – Secure Shell

49. scp – Secure Copy

50. tmux – Terminal Multiplexer

Bonus: Aliases for Efficiency

Final Tips

Why Master These Commands?

Linux vs Unix: Which Should You Choose for Development in 2026?

Linux vs Unix: Which Should You Choose for Development in 2026?

The Historical Divide

Unix: The Foundation

Linux: The Open-Source Revolution

Architecture and Design

Kernel

Filesystem Hierarchy

Licensing and Cost

Unix: Proprietary Roots

Linux: Open Source Dominance

Development Ecosystem

Package Management

1. `ls` – List Files

2. `cat` – Display File Content

3. `touch` – Create Empty Files

4. `rm` – Remove Files/Directories

5. `cp` – Copy Files/Directories

6. `mv` – Move/Rename Files

7. `find` – Search for Files

8. `grep` – Search Text Patterns

9. `head` / `tail` – View File Snippets

10. `wc` – Count Words, Lines, Characters

11. `pwd` – Print Working Directory

12. `cd` – Change Directory

13. `mkdir` – Create Directories

14. `rmdir` – Remove Empty Directories

15. `tree` – Display Directory Structure

16. `top` / `htop` – Monitor Processes

17. `df` – Disk Space Usage

18. `du` – Directory Space Usage

19. `free` – Memory Usage

20. `uptime` – System Uptime

21. `ping` – Test Network Connectivity

22. `curl` – Transfer Data via URLs

23. `wget` – Download Files

24. `ifconfig` / `ip` – Network Interfaces

25. `netstat` / `ss` – Network Statistics

26. `apt` (Debian/Ubuntu) – Package Manager

27. `yum` (RHEL/CentOS) / `dnf` (Fedora)

28. `snap` – Universal Package Manager

29. `flatpak` – Sandboxed Applications

30. `ps` – List Running Processes

31. `kill` – Terminate Processes

32. `pkill` – Kill Processes by Name

33. `bg` / `fg` – Background/Foreground Jobs

34. `jobs` – List Background Jobs

35. `chmod` – Change File Permissions

36. `chown` – Change Ownership

37. `umask` – Set Default Permissions

38. `sed` – Stream Editor

39. `awk` – Pattern Scanning

40. `sort` – Sort Lines

41. `uniq` – Remove Duplicate Lines

42. `cut` – Extract Sections from Files

43. `tar` – Archive Files

44. `gzip` / `gunzip` – Compress/Decompress

45. `zip` / `unzip` – ZIP Archives

46. `cron` – Schedule Tasks

47. `rsync` – Remote File Sync

48. `ssh` – Secure Shell

49. `scp` – Secure Copy

50. `tmux` – Terminal Multiplexer

1. `site:`

2. `inurl:`

3. `intitle:`

4. `intext:`

5. `filetype:`

6. Exact Search `"..."`

7. Excluding Results with `-`

8. `OR`

2. Never Use `robots.txt` as Access Control