Programming Languages for Hacking: What the Tools Are Written In

Last updated: September 2026. Written by Josh Hutcheson, OnlineCourseing editor. See our review methodology.

THE SHORT ANSWER

First: does security work actually require coding?

Worth settling before you spend six months on a language. The honest answer is that it depends on the role, and a lot of security work involves very little code.

Governance, risk and compliance, security awareness, audit, most SOC analyst work and much of identity administration are configuration, process and investigation jobs. You will read logs and query things. You will not usually be writing programs. Plenty of people build entire careers here without coding beyond a spreadsheet formula.

Offensive work is different. Penetration testing, red teaming, exploit development, malware analysis and detection engineering all involve reading code you did not write and producing code to automate what you found. You do not need to be a professional software engineer. You do need to be able to read a language well enough to spot a flaw in it, and write enough of one to script a task you will repeat.

That distinction is the useful one. If you are heading for a defensive or governance role, learn enough Python to automate your own work and stop. If you are heading for offensive work, keep reading.

The two questions hiding inside “best hacking language”

Standard listicles rank ten languages in one column, which is why their orderings disagree with each other and with themselves. Split the question and the answers get stable:

C appears in both columns, which is why it has a reputation as the serious answer. Everything else sits clearly on one side.

Axis one: the languages you attack

These are read far more often than written. Fluency is not the goal; recognizing a dangerous pattern is.

JavaScript

The language of every web front end and, through Node.js, a great deal of the back end. It is where cross-site scripting lives, where client-side logic gets trusted that should not be, and where secrets end up in bundles that ship to the browser. If you test web applications, this is not optional. See website hacking techniques.

SQL

Not a general-purpose language, and still one of the highest-value things on this list. You need enough to understand how user input reaches a query and what a malicious one does when it gets there. SQL injection is decades old, still found, and still catastrophic. Our SQL courses cover the fundamentals.

PHP

Unfashionable and everywhere. It still runs a very large share of the web, WordPress most visibly, which means a large share of real-world web targets are PHP applications. File inclusion, insecure deserialization and weak type comparison are the recurring themes.

Java

The default for large enterprise applications and the base of the Android platform. Deserialization flaws and dependency vulnerabilities are the usual routes in, and the fallout tends to be large because the applications are.

C and C++

The languages behind operating systems, browsers, network daemons and embedded devices. This is where memory-safety bugs live: buffer overflows, use-after-free, integer overflows. Reading C is the entry requirement for binary exploitation and for most vulnerability research.

Axis two: what the tools are actually written in

Rather than assert which languages matter for building, we checked. Below are eighteen security tools in common professional use, with the primary language GitHub reports for each repository and its star count at the time of writing. This is a sample of well-known tools, not a census, but the pattern is clear enough to act on.

The tally across those eighteen: Python 6, Go 5, C 4, C# 2, Ruby 1.

Two things in that result are worth stopping on. Go is second, ahead of C, and it appears in almost none of the standard language rankings for hacking. A whole generation of modern tooling was written in it because it cross-compiles to a single static binary, which is exactly what you want when you need something to run on a host you do not control. Perl, PHP and JavaScript implement none of the eighteen, despite Perl and PHP appearing high on most published lists, including the previous version of this page.

That is not an argument that PHP is useless. PHP sits firmly in axis one: you attack it, you do not build with it. Conflating those two roles is exactly what makes the standard rankings feel arbitrary.

What to learn, in order

Ranked for someone starting now and aiming at offensive security work, with the reasoning attached rather than a number.

1. Python

The correct first answer and the only unambiguous one. Six of our eighteen tools are written in it, the ecosystem for scripting network and web work is unmatched, and it is the language you will actually use to glue everything else together. Impacket alone makes Python worth learning for anyone touching Windows networks. Start with our Python courses.

2. Bash and PowerShell

Shell scripting is the least glamorous entry here and among the most used. Bash for Linux hosts and pipelines, PowerShell for anything Windows or Active Directory, where it is also the standard living-off-the-land tool for attackers precisely because it is already installed. See Windows pentesting tools.

3. JavaScript and SQL together

If you are testing web applications, these two cover most of what you will actually meet. Learn them as reading languages first.

4. C

The investment that pays off latest and longest. You need it to understand memory-safety bugs, to read exploit code, and to make sense of what a debugger is showing you. Four of the eighteen tools are C, including Nmap and Mimikatz.

5. Go

The one we would move up the standard list. Five of the eighteen, including Nuclei, BloodHound CE and Sliver. Easy to pick up after Python, and increasingly the language new offensive tooling is written in.

6. C#

Specialist but sharply useful if you work in Windows and Active Directory environments, where the GhostPack tooling and much of the .NET tradecraft lives.

What we would drop from the standard list

The previous version of this page ranked ten languages, and two of them no longer earn their place. Saying so is more useful than quietly reordering.

Perl

Perl was genuinely central to security tooling for years and it is not any longer. None of the eighteen tools above are Perl. You will still meet it in older scripts and in one-line text processing on systems that have not changed since the 2000s, so reading it is occasionally useful. Learning it as one of your first languages in 2026 is not. We keep Perl courses for people maintaining legacy code, which is the honest use case.

Ruby

Ruby’s relevance here is narrower than its ranking suggests, and it comes down to one thing: Metasploit is written in Ruby. That is a real reason, and if you intend to write or modify Metasploit modules it becomes the reason. If you do not, Ruby is not the second language to reach for. Note how the sample reflects this: Ruby appears once, and that once is Metasploit.

Two more the standard lists miss

Assembly

Not a language you will write applications in, and unavoidable if you go near binary exploitation, malware analysis or vulnerability research. When a debugger or disassembler shows you what a program is really doing, it shows you assembly. You do not need to be fluent across every architecture; you need to read x86-64 and increasingly ARM well enough to follow control flow and spot where memory is being handled badly. It is the natural companion to C rather than a substitute for it.

Rust

Worth watching on both sides of the line. Defensively it is memory-safe by design, which removes an entire class of the bugs that make C interesting to attackers, and that is why it keeps appearing in government guidance on secure development. Offensively it has started showing up in tooling for the same reason Go did, namely fast static binaries: RustScan and feroxbuster are both Rust and both widely used. It is not a first language, and it is a reasonable third or fourth.

Which languages for which role

The general ranking above assumes offensive security. If you already know the job you want, the list shortens considerably. Nobody needs all of these.

The last row is not a joke and it is not a lesser career. A large share of well-paid security work is governance and risk, and candidates routinely delay entering the field for a year teaching themselves a language the role will never ask them to use.

How well do you actually need to know them?

The standard that matters is lower than most people assume, and it is different for the two axes.

For languages you attack: reading fluency

You need to open an unfamiliar file and follow what it does. Where does input enter, what happens to it, what is trusted that should not be. You do not need to be able to build an application in the language, and trying to reach that standard in five languages is how people spend two years not becoming testers.

For languages you build with: working fluency in one

Pick one, usually Python, and get genuinely comfortable: parsing output, making HTTP requests, handling files and errors, and stitching tools together. One language you can actually finish something in beats six you have watched tutorials about. Everything after that is easier, because the second language is mostly syntax.

Does AI-assisted coding change the answer?

It changes the balance between the two kinds of fluency, and it changes it in a direction that makes this page’s split more useful rather than less.

Writing a throwaway script is genuinely easier than it was. If you need something to parse an output file, walk a list of hosts or reshape some JSON, a model will produce a workable first attempt in most languages, and the value of having memorized syntax drops accordingly. That is a real shift and it is worth acknowledging rather than pretending otherwise.

What it does not do is remove the need to read. If anything the opposite: you are now reviewing more code that you did not write, some of which is confidently wrong, and in security the cost of shipping something confidently wrong is higher than in most fields. A generated exploit that behaves differently from how it reads is a hazard to the person running it and to the client’s systems. The skill that has appreciated is judging whether code does what it claims.

The practical consequence: weight your effort toward reading fluency across several languages and one language you genuinely control, which is what we recommended above for entirely separate reasons. Treat generated code as a draft from a fast, uneven colleague who has never seen your target.

What changed since this list was first written

This page originally ranked ten languages in 2021, and the honest way to update it is to say what moved rather than silently reorder.

Go went from absent to second. The tooling written in it since, Nuclei and BloodHound CE among others, did not exist in its current form or was far less established. Perl dropped out on the evidence rather than on taste. PowerShell and C# moved up as Active Directory tradecraft became the center of gravity for internal testing. And the framing changed, which matters more than the ordering: a single ranked list of ten languages was never a good answer to a question that contains two questions.

Frequently asked questions

What is the best programming language for hacking?

Python, if you have to pick one. It is the most common implementation language among widely used security tools, and it is what you will write your own automation in. But the question is usually the wrong one: the language you need depends on whether you are attacking something or building something.

Does cyber security require coding?

It depends on the role. Governance, compliance, audit and much SOC work require little or no programming. Offensive roles such as penetration testing, red teaming and exploit development do, because you will need to read a target’s code and automate what you find. You do not need to be a software engineer either way.

Should I learn Python or C first for hacking?

Python first, in almost every case. It gets you productive quickly, it is what most tooling is written in, and it is what you will script with daily. C is the deeper investment and matters enormously for binary exploitation and vulnerability research, but it is a poor first language for someone who wants to be useful within a few months.

Is Go worth learning for security work?

More than the standard rankings suggest. In our sample of eighteen tools, Go was second only to Python, including Nuclei, ffuf, Gobuster, BloodHound CE and Sliver. It compiles to a single static binary that runs without a runtime installed on the target, which is precisely why offensive tooling has moved toward it.

Do I still need to learn Perl for ethical hacking?

No. Perl was once central and is not now. None of the eighteen tools we checked use it. Being able to read a Perl script you inherit is mildly useful; making it one of your first languages is not a good use of time.

Why is Ruby on every list of hacking languages?

Essentially because of Metasploit, which is written in Ruby and is one of the most widely used exploitation frameworks. If you plan to write or modify Metasploit modules, that is a genuine reason to learn it. Otherwise Ruby’s role in security tooling is small.

Where to learn this properly

Languages are the substrate, not the skill. Knowing Python does not make you a tester any more than knowing English makes you a novelist. What turns one into the other is method: scoping, reconnaissance, exploitation and reporting, practiced against systems you are permitted to attack. Our penetration testing methodology sets out that sequence, and is ethical hacking legal? covers why permission is the part that matters most.

For structured training we rank the options on merit in best ethical hacking courses for offensive security and best cyber security courses for the broader defensive track, including which ones we would not pay for.

See the ranked ethical hacking courses →

Related guides

• ethical hacking tools — the professional toolkit these languages build
• Windows pentesting tools — where PowerShell and C# do the work
• website hacking techniques — the attacks JavaScript, PHP and SQL enable
• password hacking techniques — online, offline and bypass
• types of hackers — which hat colors are real and which are folklore
• glossary of hacking terms — the 78-term glossary, grouped by attack stage
• penetration testing methodology — how a scoped engagement runs
• Is ethical hacking a good career? — the honest numbers, including the downsides