What's wrong with using $_REQUEST[]?

Question

I've seen a number of posts on here saying not to use the $_REQUEST variable. I usually don't, but sometimes it's convenient. What's wrong with it?

Educatee

See related question and answers: #1149618 – Speckle

Since php 5.3 the default php.ini says only GET and POST data are put into $_REQUEST. See php.net/request_order I just stumbled on this backwards-compatibility break when expecting cookie data to be in $_REQUEST and wondering why it wasn't working! So the biggest reason to avoid using $_REQUEST is now that your script cannot set request_order itself (it is PHP_INI_PERDIR), so a php.ini change can easily break assumptions your script is built on. Better to put those assumptions directly into your script. – Speedball

Answer 1

There's absolutely nothing wrong with taking input from both $_GET and $_POST in a combined way. In fact that's what you almost always want to do:

• for a plain idempotent request usually submitted via GET, there's the possibility the amount of data you want won't fit in a URL so it has be mutated to a POST request instead as a practical matter.

• for a request that has a real effect, you have to check that it's submitted by the POST method. But the way to do that is to check $_SERVER['REQUEST_METHOD'] explicitly, not rely on $_POST being empty for a GET. And anyway if the method is POST, you still might want to take some query parameters out of the URL.

No, the problem with $_REQUEST is nothing to do with conflating GET and POST parameters. It's that it also, by default, includes $_COOKIE. And cookies really aren't like form submission parameters at all: you almost never want to treat them as the same thing.

If you accidentally get a cookie set on your site with the same name as one of your form parameters, then the forms that rely on that parameter will mysteriously stop working properly due to cookie values overriding the expected parameters. This is very easy to do if you have multiple apps on the same site, and can be very hard to debug when you have just a couple of users with old cookies you don't use any more hanging around and breaking the forms in ways no-one else can reproduce.

You can change this behaviour to the much more sensible GP (no C) order with the request_order config in PHP 5.3. Where this is not possible, I personally would avoid $_REQUEST and, if I needed a combined GET+POST array, create it manually.

Radiometeorograph

These situations (data too long to be submitted via GET) are an exception, not a rule – Cohlette

Nice answer. I also noticed that with frameworks such as Zend Framework GET and POST params are combined into 1 request object. It never struck me until I read your post. – Safir

By default the request_order configuration is set to "GP" in php.ini as of PHP 5.4+ so I'd say go for it... but as always, proceed with caution. – Hispanic

if $_POST is a="foo" and $_COOKIE a="bar", then will there be any override/conflicts here? – Maynord

Answer 2

I've been digging through some newsgroup posts on PHP Internals and found an interesting discussion about the topic. The initial thread was about something else, but a remark by Stefan Esser, a (if not the) security expert in the PHP world turned the discussion towards the security implications of using $_REQUEST for a few posts.

Citing Stefan Esser on PHP Internals

$_REQUEST is one of the biggest design weaknesses in PHP. Every application using $_REQUEST is most probably vulnerable to Delayed Cross Site Request Forgery problems. (This basically means if e.g. a cookie named (age) exists it will always overwrite the GET/POST content and therefore unwanted requests will be performed)

and in a later reply to the same thread

It is not about the fact that someone can forge GET, POST; COOKIE variables. It is about the fact that COOKIEs will overwrite GET and POST data in REQUEST.

Therefore I could infect your browser with a cookie that says e.g. action=logout and from that day on you cannot use the application anymore because REQUEST[action] will be logout forever (until you manually delete the cookie).

And to infect you with a COOKIE is so simple...
a) I could use an XSS vuln in any application on a subdomain
b) Ever tried setting a cookie for *.co.uk or *.co.kr when you own a single domain there?
c) Other cross domain whatever ways...

And if you believe that this is not an issue then I can tell you that there is a simple possibility to set f.e. a *.co.kr cookie that results in several PHP versions just returning white pages. Imagine: Just a single cookie to kill all PHP pages in *.co.kr

And by setting an illegal session ID in a cookie valid for *.co.kr in a variable called +PHPSESSID=illegal you can still DOS every PHP application in korea using PHP sessions...

The discussion continues for a few more postings and is interesting to read.

---

As you can see, the main problem with $_REQUEST is not so much that it has data from $_GET and $_POST, but also from $_COOKIE. Some other guys on the list suggested changing the order in which $_REQUEST is filled, e.g. filling it with $_COOKIE first, but this could lead to numerous other potential problems, for instance with Session handling.

You could completely omit $_COOKIES from the $_REQUEST global though, so that it is not overwritten by any of the other arrays (in fact, you can limit it to any combination of it's standard contents, like the PHP manual on the variable_order ini setting tells us:

variable_order Sets the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing. For example, if variables_order is set to "SP" then PHP will create the superglobals $_SERVER and $_POST, but not create $_ENV, $_GET, and $_COOKIE. Setting to "" means no superglobals will be set.

But then again, you might also consider not using $_REQUEST altogether, simply because in PHP you can access Environment, Get, Post, Cookie, and Server in their own globals and have one attack vector less. You still have to sanitize this data, but it's one less thing to worry about.

---

Now you might wonder, why does $_REQUEST exists after all and why it is not removed. This was asked on PHP Internals as well. Citing Rasmus Lerdorf about Why does $_REQUEST exist? on PHP Internals

The more stuff like this we remove, the harder it becomes for people to quickly move to newer, faster and more secure versions of PHP. That causes way more frustration for everyone than a few "ugly" legacy features. If there is a decent technical reason, performance or security, then we need to take a hard look at it. In this case, the thing we should be looking at isn't whether we should remove $_REQUEST but whether we should remove cookie data from it. Many configurations already do that, including all of my own, and there is a strong valid security reason for not including cookies in $_REQUEST. Most people use $_REQUEST to mean GET or POST, not realizing that it could also contain cookies and as such bad guys could potentially do some cookie injection tricks and break naive applications.

Anyway, hope that shed some light.

Speckle

I think that discussion was a bit overgeneralized. The actual problem is developer unawareness, not the the existence of cookies in $_REQUEST per se. The fixated PHPSESSID for example is going to be reset with a per-domain cookie anyway with contemporary session handling code. And for some applications a cookie overriding request vars might really be desirable (e.g. sort_order=ASC overrides a search form GET var). Though coding in such behaviour explicitly is more sensible. – Spiritualist

Sadly, Rasmus commented on this in 2009, and yet $_REQUEST is essentially the same now, in 2015. – Tecu

Answer 3

$_REQUEST refers to all sorts of requests (GET, POST etc..). This is sometimes useful, but is usually better to specify the exact method ($_GET, $_POST etc).

Swine

This answer describes what $_REQUEST is, but it doesn't answer the question. – Exhilaration

He is saying that it is just better practice to know what type of request would be incoming and to code to that specific request. – Telugu

Answer 4

$_REQUEST is generally considered harmful for the same reason that simple-to-medium-complexity data-transformations are often performed in the application code instead of declared in SQL: some programmers suck.

As such, if one tends to use $_REQUEST everywhere, I can do anything via GET that I could via POST, which means setting up <img> tags on my (malicious) site that cause users logged into your e-commerce module to purchase products silently, or I can cause them to click on links that will result in dangerous actions or the revelation of sensitive information (probably to me).

However, this is because of a novice, or at least inexperienced, PHP programmer making simple mistakes. First off, know when data of what type is appropriate. For example, I have a web service which can return responses in URLEncoding, XML or JSON. The application decides how to format the response by checking the HTTP_ACCEPT header, but can be coerced into one specifically by sending the format parameter.

When checking the content of the format parameter, it could be sent via querystring or a postdata, depending on a multitude of factors, not the least of which being whether or not the calling applications wants "&format=json" mixed in with its request. In this case, $_REQUEST is very convenient because it saves me having to type something like this:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

I'm not going to ramble on much further, but suffice to say that $_REQUEST usage is not dissuaded because it is inherently dangerous - it's just another tool that does exactly what is asked of it, whether you understand those implications or not - it is the poor, lazy or uninformed decision of a poor, lazy or inexperienced programmer that causes this problem.

###How to use $_REQUEST safely###

---

0. Know your data: You should have some expectation as to what kind of data you will get, so sanitize it accordingly. Data for a database? addslashes() or *_escape_string(). Going to show it back to the user? htmlentities() or htmlspecialchars(). Expecting numerical data? is_numeric() or ctype_digit(). In fact, filter_input() and its related functions are designed to do nothing but check and sanitize data. Use these tools, always.
1. Don't access user-supplied superglobals data directly. Make a habit of sanitizing your data, every time, and move your data to clean variables, even if it's just $post_clean. Alternatively, you can just clean directly in the superglobals, but the reason I advocate using a separate variable is because doing so makes it easy to spot vulnerabilities in code, as anything pointing directly to a superglobal and not its sanitized equivalent is considered a dangerous error.
2. Know where you data should be coming from. Referencing my example from above, it is perfectly reasonable to allow the response format variable to be sent via GET or POST. I also allow the "action" variable to be sent via either method. However, the actions themselves have very specific requirements as to which HTTP Verb is acceptable. Functions, for example, that make changes to data used by the service may only be sent via POST. Requests for certain types of non- or low-privilege data (such as dynamically generated map images) may be served in response to requests from either method.

In conclusion, remember this simple rule: ##SECURITY IS WHAT YOU MAKE IT, PEOPLE!##

###EDIT:### I strongly recommend bobince's advice: if you can, set the request_order parameter in php.ini to "GP"; that is, no cookie component. There is almost no rational reasoning for this in 98%+ of cases, as cookie data should almost never be considered comparable to the querystring or to postdata.

P.S., Anecdote!

I knew a programmer who thought of $_REQUEST a place to simply store data that was accessible in a superglobal way. Important usernames and passwords, paths to files, you name it and it was stored in $_REQUEST. He was a bit surprised (although not comically so, unfortunately) when I told him how that variable behaves. Needless to say, that practice has been deposed.

Conifer

Answer 5

GET requests should be idempotent and POST requests are generally not. This means that data in $_GET and $_POST should generally be used in different ways.

If your application is using data from $_REQUEST, it will behave the same for both GET and POST requests, which violates the idempotence of GET.

Cohlette

but doesn't that depend on the implementation? "Indempotent" is a new word for me, but if I'm understanding it correctly, it would be easy to imagine setting up a GET situation that wasn't indempotent. For example, page counters generally increase each time you request a given url. – Educatee

@Educatee - as well, you can have situations where you have both GET data and POST data in the same request, in which case the request method is essentially meaningless when contextualized with the request data. – Exhilaration

sprugman, obviously any GET request modifies something because it is logged by the web server. It can still be indempotent in the domain of the application, where this metadata does not really matter. – Cohlette

@Educatee - the general idea here is that you shouldn't have a GET request that modifies data. A typical example of why this is bad would be a web spider crawling your site and following links that unintentionally modify the data. For example the "flag" link on an SO post. – Bloom

That was a trivial example. How about if I'm using GET via ajax because it's faster (as suggested in this post on carsonified carsonified.com/blog/dev/the-definitive-guide-to-get-vs-post). – Educatee

Side note: The correct term is idempotent, not indempotent. en.wikipedia.org/wiki/Idempotence – Spradlin

Answer 6

It's vague. You don't really know how the data got to you since it carries post, get, and cookie data. I don't necessarily think that is always a bad thing, unless you need to know or restrict the method of delivery.

Lammers

Answer 7

I actually like using it. It gives you the flexibility to use GET or POST which can come in handy for things like search forms where most of the time data is POSTed, but sometimes you'll want to say link to a particular search, so you can use GET parameters instead.

Also, if you look at many other languages (ASP.NET for example) they make no distinction between GET and POST variables at all.

ETA:

I've never used REQUEST to get COOKIE values, but I think Kyle Butt makes a great point in the comments on this post about that. It is NOT a good idea to use REQUEST for getting COOKIE values. I believe he is right that there is some real potential for cross-site request forgery if you do that.

Also, the order in which stuff gets loaded into REQUEST is controlled by configuration parameters in php.ini (variables_order and request_order). So, if you have the same variable passed in via both POST and GET, which one actually gets into REQUEST depends on those ini settings. This could affect portability if you depend on a particular order and those settings are configured differently than you expect them to be.

Bloom

that's an awful mistake. How can you guarantee that non-idempotent actions were carried out over a POST? – Buschi

it's injection source, stop using it – Jardiniere

@Kyle - by not using it for non-idempotent actions. I certainly wouldn't use it for everything, just pointing out that it IS useful, like for searches as I mentioned in my example. – Bloom

@Jardiniere - Can you explain to me how you would inject something via GET that could not be injected via POST? – Bloom

Wow, a lot of harsh downvotes on this one. This is an entirely correct answer. @Jardiniere - There is no security difference between using $_REQUEST over any of the other superglobals. – Exhilaration

I agree with Eric's points, it definitely comes handy for search forms or in scenarios that you don't care how you get the data. ASP.NET indeed has no distinction between the two, but ASP.NET MVC does. – Addictive

by placing a reference on my site to a page on your site with query parameters in it, I can use your content (which may be sensitive, and generated based on any cookies for your domain the user possesses) in my site, including using javascript to send it to my webserver. That's not possible with post. – Buschi

This magical idea that _POST is secure and _GET is not has got to go. If I am not using your software correctly, then there is very little (if any) difference to me in sending a POST request versus a GET request. Security is in what you do with the data, not where it came from. As for the simple XSS/Request exploits, it is entirely possibly it use _REQUEST only for values that would be valid with either POST or GET, and use _POST only for things which should be POSTed. Common sense, not magical superglobal usage. – Conifer

@Conifer - What makes you think _POST is secure and _GET is not? From the attacker's perspective, he/she can manipulate the input in any way he/she desires. How you do input validation and output validation are the essences. – Addictive

@Kyle - I still don't see how you couldn't do what you mention just as easily using something like curl() or an ajax post to pass that same data in via POST and COOKIE. Whether you use REQUEST, GET, POST or COOKIE, all the data is ultimately coming from the client and can always be faked. – Bloom

+1 @Dereleased, absolutely correct. @Kyle - just because you can easily create a link to another page (GET), doesn't mean POST is secure. It takes 5 seconds to whip up a cURL request with whatever data you want and send it via POST. – Exhilaration

@zombat: The curl request you form won't be logged in as a vulnerable user. The link that you create and place on your site will. @Dereleased: It's not magical thinking, and there are still vulnerabilities galore with GET. but it IS more secure to trust a POST from a logged in user than a GET from a logged in user. – Buschi

@Jay: I don't, my comment was meant to imply specifically that it is not any more secure. – Conifer

Answer 8

The only time using $_REQUEST is not a bad idea is with GET.

• If you use it to load POST values, you risk cross-site request forgeries
• If you use it to load cookie values, you again risk cross-site request forgeries

And even with GET, $_GET is shorter to type than $_REQUEST ;)

Brundisium

While I agree with you, I think it's important to note why this is true and/or dangerous: one should use $_POST when it is important that the data be POSTDATA. One should use $_REQUEST when the data is agnostic to the HTTP Verb used. One should in all of these cases carefully sanitize all input data. – Conifer

I don't see how the source of the data pertains to the likelihood of cross-site request forgery. An attacker can set a POST parameter perfectly easily by supplying the user with a POST form pointed at your site; you're going to need the same anti-XSRF protection measures regardless of whether a submission comes from GET or POST. – Radiometeorograph

It's much easier to abuse GET for forgery. For example, you can simply have an img tag with its src set with the parameters you want. It'll work without the user ever knowing it was there. – Brundisium

Answer 9

It's important to understand when to use POST, when to use GET and when to use a cookie. With $_REQUEST, the value you're looking at could have come from any of them. If you expect to get the value from a POST or a GET or from a COOKIE, it's more informative to someone reading your code to use the specific variable instead of $_REQUEST.

Someone else pointed out also that you don't want to all POST's or cookies to be overridden by GETs because there are different cross-site rules for all of them, for instance, if you return ajax data while using $_REQUEST, you are vulnerable to a cross site script attack.

Buschi

Answer 10

I might be used only if you want to retrieve the current url or hostname, but for actually parsing data from that URL such as parmeters using the & symbol it's probably not a good idea. In general, you don't want to use a vague description of what you are trying to do. If you need to be specific that's where $_REQUEST is bad, if you don't need to be specific then feel free to use it. I would think.

Luhe

What are you trying to say? Are you confusing $_REQUEST with $_SERVER['QUERY_STRING']? – Conifer

Answer 11

If you know what data you want, you should explicitly ask for it. IMO, GET and POST are two different animals and I can't think of a good reason why you would ever need to mix post data and query strings. If anyone has one, I'd be interested.

It can be convenient to use $_REQUEST when your scripts might respond to either GET or POST in the same manner. I would argue though that this should be an extremely rare case, and in most instances two separate functions to handle two separate concepts, or at the very least checking the method and selecting the correct variables, is preferred. Program flow is usually a lot easier to follow when it's not necessary to cross reference where the variables might be coming from. Be kind to the person who has to maintain your code in 6 months time. It might be you.

In addition to the security problems and WTFs caused by cookies and environment variables in the REQUEST variable (don't get me started on GLOBAL), consider what might happen in the future if PHP started natively supporting other methods such as PUT and DELETE. While it's extremely unlikely that these would be merged into the REQUEST superglobal, it's possible they could be included as on option in the variable_order setting. So you really have no idea whatsoever what REQUEST holds, and what is taking precedence, particularly if your code is deployed on a third-party server.

Is POST safer than GET? Not really. It's better to use GET where practical because it's easier to see in your logs how your application is being exploited when it gets attacked. POST is better for operations that affect domain state because spiders generally don't follow them, and predictive fetching mechanisms won't delete all your content when you log into your CMS. However, the question was not about the merits of GET vs POST, it was about how the receiver should treat the incoming data and why it's bad to merge it, so this is really just a BTW.

Violist

Answer 12

I think there is no problem with $_REQUEST, but we must be careful when using it since it is a collection of variables from 3 sources (GPC).

I guess $_REQUEST is still available to make old programs compatible with new php versions, but if we start new projects (including new libraries) I think we should not use $_REQUEST anymore to make the programs clearer. We should even consider deleting uses of $_REQUEST and replacing it with a wrapper function to make the program lighter, especially in processing large submitted text data, since $_REQUEST contains copies of $_POST.

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Ching

Answer 13

Darren Cook: "Since php 5.3 the default php.ini says only GET and POST data are put into $_REQUEST. See php.net/request_order I just stumbled on this backwards-compatibility break when expecting cookie data to be in $_REQUEST and wondering why it wasn't working!"

Wow... just had some of my scripts stop working because of an upgrade to PHP 5.3. Did the same thing: assume that cookies would be set when using the $_REQUEST variable. With the upgrade exactly that stopped working.

I now call cookie values separately using $_COOKIE["Cookie_name"]...

Ayers

Answer 14

Just make sure to set correct parameter in your php.ini (below is default, as long as not set to GPC, no Cookies are used here)

request_order = "GP"

which means POST overwrites GET and you'll be fine.

The reason for $_REQUEST is simply consolidation of $_GET and $_POST. When sending a form and navigation through lots of links on your page, it is very usefull to have one place which holds the state: $_REQUEST

Psi

Answer 15

The central problem is that it contains cookies, as others have said.

In PHP 7 you can do this:

$request = array_merge($_GET ?? [], $_POST ?? []);

This avoids the cookie problem and gives you at worst an empty array and at best a merger of $_GET and $_POST with the latter taking precedence. If you are not too bothered with allowing URL injection of parameters through the query string, it's quite convenient.

Laclos

Answer 16

It's very insecure. Also it's awkward since you don't know if you're getting a POST or a GET, or another request. You really should know the difference between them when designing your applications. GET is very insecure as it's passed in the URL and is not suitable for almost anything besides page navigation. POST, while not safe by itself either, provides one level of safetey.

Whitmire

There is no difference in safety between $_POST and $_GET, other than you can't type a POST request into a browser URL bar. It only takes 5 seconds to whip up a command-line cURL request utilizing POST however. – Exhilaration

@Zombat: We need to start some kind of campaign to convince people that POST is not inherently safe, or even safer, than GET. Security is in how you treat data not what HTTP Verb was used to get it there. – Conifer

@Conifer - I propose an iconic duo-tone picture of a cloud with some lightning bolts to represent the internet, with the word "CHANGE" underneath. – Exhilaration

@Exhilaration I think you skipped the part where I said it's also not secure. However, with POST you can't see the parameters. – Whitmire

@StanislavPalatnik -1 ^ ... You can see the parameters with developer tools and you can tamper them. In other words: there is no difference in security between $_POST and $_GET. – Stairway

@GuyT: That's a very narrow minded view. It's not just about how "secure" it is, but how confidential it is. GET parameters can show up as autocompletes in the browser url, even browser history. Also, security doesn't end with the browser. For example, many servers log http urls, so anything in the url would get logged, for example. Having a username/password show up in the logs Does make a difference. On the safe side, always avoid passing sensitive information as GET parameters. – Whitmire

@StanislavPalatnik In your answer you said that GET is insecure 'as it's passed in the URL'. I think you miss the whole point. There is no difference betweeen $_GET or $_POST. It doesn't matter if you can see the parameters or not. In both cases you can tamper them. Besides, nowadays the browser will autocomplete almost every input. If you even think about sending usernames/passwords or other sensitive information through the URL than we have to end this discussion. – Stairway

@GuyT: "If you even think about sending usernames/passwords or other sensitive information through the URL than we have to end this discussion" - You just proved my point. Also brush up on what POST actually means and if you do then brush up on what autocomplete means or find me an example where a browser "autocompletes" POST parameters. – Whitmire

@StanislavPalatnik I've created a jsFiddle for you to show the autocompletion: jsfiddle.net/GuyT/65aW8 . Fill in name and password. Hit the send button. Rerun the fiddle and the POST parameters will be autocompleted(Chrome 35.0.1916.114 m). – Stairway

@GuyT: I think we have a misunderstanding. A form doesn't behave any differently if it's action is a GET or POST. I'm not talking about auto-completing forms, that's a UI issue. I'm talking about auto-completing GET/POST requests in general. You cannot accidentally autocomplete a POST request in the browser address bar, because the parameters are not sent in the url. This is not to say that POST parameters are more secure, but it prevents accidental leaking of info which could easily be avoided. – Whitmire

@Dereleased: I did not say POST is "safe", I said it's "safer", because of the discussion above. It's nice to know the difference. – Whitmire

@StanislavPalatnik I think you are the only one who doesn't get that there is no difference between them. I repeat: if you even think about sending sensitive information through the URL(what could be seen in the log files) you are missing a full chapter of security. The only reason I could think of to use $_GET is for a dynamic page system(together with a .htaccess) or for SEO reasons. – Stairway

@GuyT: Dude, that's exactly what I'm saying. Don't send sensitive stuff through the url. With POST, the data is sent in the HTTP body, not in the url header. Using GET is much more insecure than POST, but neither of them are safe all by themselves. – Whitmire

In your answer you say literally: ... provides one level of safetey. This is not true. It is maybe harder to see than a $_GET, but I doubt that. If you are a hacker you are known with this techniques. – Stairway

@GuyT: Dude, I don't know of you're just trolling me or what. I clearly state that neither GET or POST are safe by themselves - "but neither of them are safe all by themselves". It's not like I'm saying if you use POST you can send your CC number in plaintext -- ok --, but that you should prefer POST over GET because it makes it harder to easily snoop as I mentioned above - parameters in the url, in the logs, etc. Maybe the better perspective is it makes it harder to accidently leak data. But if you wnt to justify your downvote and think Im actually saying POST is secure then by all means. – Whitmire

Specifically the Apache access logs. Any request url will get logged, and ANYONE who has access to the logs can see your credentials coming through. – Whitmire

The question of safety is different from why to use REQUEST! Both GET and POST can be regarded as unsafe as everyone can modify them. – Psi