Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've came across that question on StackOverflow:

The claim is made, that according to Wikipedia:

A final class cannot be subclassed. This is done for reasons of security and efficiency.

and the OP asked, how the security is achieved using final keyword.

What surprised me, most answers were claiming, that the final keyword would greatly increase security, because attacker won't be able to override your classes and calling your protected methods etc. They are mostly based on Oracle's article Secure Coding Guidelines

For example, making a class final prevents a malicious subclass from adding
finalizers, cloning, and overriding random methods

However, with my understanding, if the attacker gains the possibility to execute arbitrary Java code on the targeted system (and if you are considered of him overriding your classes, he is expected to be) than he can already do everything your code is able to do, therefore it's completely irrelevant from security point of view, if your methods are final or not, or even if fields are private and not exposed or not (he can serialize your class and read every field etc.).

But on the other side, is it possible to find such real-life scenario, when attacker wouldn't achieve his goals by executing arbitrary code, and he would succeed only (or such attack would be considerably easier) by 'maliciously' overriding your classes, such as described in Oracle's article? For example, if the application server is shared by multiple Java applications?

share|improve this question

This feature of Java makes sense, security-wise, in the Applet model: a context where, indeed, the attacker gets to execute his code on your machine, and yet that potentially hostile code is still contained. This was meant initially for Web browsers, not for servers.

All the containment of a Java applet is performed on a per-call basis, in a very fine-grained way. There is a complex framework of permissions which encode what the applet can do and what it cannot do. In particular, a basic applet cannot perform arbitrary serialization of code, or reflection to inspect and/or modify instances out of its own package, or call native code. The final keyword also makes sense in that context: since String is final, then the standard classes can assume that when they receive as argument a String, it is the genuine object, not an EvilString which extends String but acts in unexpected ways when its Substring() method is invoked.

It turned out that maintaining security under these conditions was a hard problem -- harder than what Sun initially believed. There are hundreds, if not thousands, of standard library classes which must be made "permission aware", and, for each of them, the code must take care to enforce the appropriate permissions. It was inevitable that the Sun people, however competent they may be, forget a few corner cases, leading to exploitable vulnerabilities. During the last few years, there has been a steady stream of "Java applet vulnerabilities" which allow an evil Web site to take control of any Web browser which visits it, as long as that browser uses a Java plugin which has not been fixed.

None of this impacts Java as a programming language, as it is often used on servers, or in big desktop applications; in these situations, indeed, there is no hostile code running locally.

The final keyword can still serve as compiler-enforced documentation (thus not against attackers, but as a reminder for careless programmers); it also helps optimization (when the JVM sees a call to a final method, or to any method on a final class, then it knows that it can optimize the call into a direct jump into the method code, since there is no way that method could be overridden).

share|improve this answer
If I have good understand you, the attacker is the applet author, the targeted machine is that of the user that opened the site, and the attacked code is JRE? – Danubian Sailor Sep 12 '13 at 18:25
Yes, that's the gist of it. In that context, it makes sense to talk about security against the application code itself, and the final keyword takes on a security-related role. – Tom Leek Sep 12 '13 at 18:34
So actually, using final keyword increases security of JRE code, but using it in applet to protect applet from malicious code, or on web application server to protect against other web applications, makes no sense? – Danubian Sailor Sep 12 '13 at 19:18
I agree to that. However, using final for code performance and clarity still makes sense, even when the Applet model does not apply. – Tom Leek Sep 12 '13 at 19:30
Securing a platform given a VM with robust type-safety and "private" isn't that difficult. So long as you don't do anything stupid, such as introducing globals. I guess if you grep the Java library you'll actually find a relatively small proportion of classes deal with permissions - those that do are hacks. The vulnerabilities in the non-native part of the Java library (of course C has vulnerabilities, that's what it does) rarely have straight forgetting a permission check as a contributory cause. – Tom Hawtin - tackline Oct 3 '13 at 18:20

There is also design security:

By flagging classes and methods as final; the development team prunes the amount of future mutation in sensitive code*. This guides the development team (which may be distributed) and any future code maintainers or enhancement projects as to where sensitive behaviour is occurring and should occur - concentrating the design risk into a smaller area.

If I recollect correctly, BouncyCastle classes that not intended for public API consumption are locked down this manner to discourage unexpected polymorphic behaviour and home-brew design of crypto-primatives within BouncyCastle. While final doesn't stop anyone from modifying the source code and recompiling as they see fit, for any project with good design, final serves a decent warning flag for new developers that mutating the method may have unexpected side-effects upon internal framework integrity. And hence upon security.

* To the great inconvenience of classically-trained OOP developers I might add.

share|improve this answer
But this is security by enforcing better design, so stating that code is more secure simply by adding final keywords can be misleading? – Danubian Sailor Sep 13 '13 at 5:02
Certainly. The final keyword is just a tool to help shape the structure of the application; a structure that the compiler then enforces within its limitations. In-and-of-itself final says nothing about whether the application is actually secure. It simply reduces the likelihood of an application becoming even more insecure due to polymorphic cowboy coding and "string == string" style mistakes. – LateralFractal Sep 13 '13 at 5:27
Good that you have accented design security. The question was if final could protect against attacks and the people from linked topic are convinced that it does. – Danubian Sailor Sep 13 '13 at 6:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.