2

I once questioned a teacher why she used to set properties visibilities as private or protected ALWAYS. She answered me that this is more secure than setting it public, but I'm not really confident in this answer. So, I want to know, even if I ensure that a final user won't have any way to manipulate my classes, is Public property really less secure for properties ? Why ?

bzim
  • 1,002
  • 9
  • 17
  • 1
    To my knowledge, it is not any more or less secure, but it's more of a way to restrict function usage across classes. – Rasclatt Nov 25 '16 at 20:10

4 Answers4

6

No, that's absolute rubbish. It is no more or less secure.

If a user wanted to, they can access a protected/private property on an object:

class Car {
    protected $engine = 'V8';
}

$reflector = new ReflectionClass('Car');
$engineProperty = $reflector->getProperty('engine');
$engineProperty->setAccessible(true);

$maserati = new Car;
echo $engineProperty->getValue($maserati); // echoes "V8"
$engineProperty->setValue($maserati, 'I4');
echo $engineProperty->getValue($maserati); // echoes "I4"

So, demonstrably, there is no security benefit.

The benefit is that it helps the end user by marking which functions and properties the class is designed for them to interact with. The developer could totally alter the internals of the class if they wanted to, but the code that calls it wouldn't have to change. If they really want to, the user of the class can muck about with it, but that's their problem if things don't work!

lonesomeday
  • 233,373
  • 50
  • 316
  • 318
  • I was thinking this, but not sure. My teacher said to me that I should -always- make a property private/protected and to use only getters and setters when I wanted them to interact with outside scope, and never use public visibility, because this way would be more secure (even if I ensure that correct values would be setted). – bzim Nov 25 '16 at 20:22
  • @BrunoCorrêaZimmermann I would disagree with whole notion of public restriction. The reasoning is not very sound, if you worked for this person/company and that was their in-house standard, I would say you would have to stick with it, but to restrict this way in general is limiting for no real benefits, certainly not from a "security" standpoint. – Rasclatt Nov 25 '16 at 20:29
  • 1
    @BrunoCorrêaZimmermann It's not a dreadful idea to have properties protected and to use getters and setters. They are more versatile and there may come a time in the future when the increased functionality is useful. Designing a class is kind of like making a contract between you and the person using the class: you promise to keep the interface the same (or at least compatible). Having private/protected properties can help this: that's why they exist. But they don't make anything more secure. – lonesomeday Nov 25 '16 at 21:03
3

Public properties are not more secure or insecure by themselves as other answers pointed out. But having many public properties can indirectly lead to less secure applications. For example:

Classes with many public properties are more difficult to reason about because those properties can be manipulated by ANY other part of the code instead of just by his own methods. This way the security of the application as a whole can become harder to manage.

In other words: public properties can lead to a bigger attack surface.

Wouter de Winter
  • 701
  • 7
  • 11
1

This has nothing to do with security. Encapsulation might be the word you/your teacher is looking for.

See What is encapsulation? How does it actually hide data?

Community
  • 1
  • 1
Shira
  • 6,392
  • 2
  • 25
  • 27
  • Maybe. But, is getter/setter encapsulation more secure than public property ? Even if I ensure that only correct values are being setted ? – bzim Nov 25 '16 at 20:21
  • No, but a good software class/package will only expose functionality that really should be accessed from other code modules. – thomasreiser Nov 25 '16 at 20:30
  • Read the accepted answer of the question I linked to :) I'm not going to copy-paste the entire thing here. It explains the main advantages of writing properly encapsulated code. *Security* is not the correct term for this. – Shira Nov 25 '16 at 20:31
  • I read. And I now that in some places this is a development standard, and that sometimes it is in fact better to hide implementation details. What I wanted to know is about security. I wanted to know if it is less secure to the final users. – bzim Nov 25 '16 at 20:37
  • From the point of security, it doesn't matter to the final users at all. It matters to people developing, maintaining and using the code itself. – Shira Nov 25 '16 at 21:17
0

Inheritance is another area which is affected by encapsulation.

New features are often added to applications by extending a base class with a child class. New developers that are hired to work on a software project usually use the public methods of classes created by other developers.

If a method is declared as public by mistake then it can be overridden by future developers

Nadir Latif
  • 3,690
  • 1
  • 15
  • 24