I am watching a training video called "Creating Secure J2EE Code". The video makes this statement:

Perform all validation in a secure context on the server. Do not rely on client-side validation as a security mechanism. Validate all application input, including user input, API return values, environment variables, configuration files, and other applications.

Validating environment variables and config files is a new concept to me. Can you please provide a high level overview of what this might look like?

My thoughts are to treat both Environment Variables and Config files similar to user input. I would:

  • Sanitize it,
  • Test Length (Min & Max),
  • Test Range,
  • Test format
  • Test type (int, decimal, char, etc)

I am assuming config files would contain Key/Value pairs. Im not certain how to handle a configuration file that may contain any other format.

Am I on the right track?

  • Normally, I only recommend validating data from untrusted sources unless it is easy to implement. For example, if your web app loads data from a business partner I would validate that if your app is going to process/display it. If it is loading a config file that only trusted admins can edit then there's less risk (depending on your threat model). It's not a bad idea to validate all data to reduce errors, but I'd focus your energy on validating untrusted data first.
    – PwdRsch
    Jun 30, 2014 at 14:46

1 Answer 1


(this should probably be a comment but i's a bit verbose)

Validating environment variables and config files is a new concept to me

At first this struck me as odd - then I remembered that not alJ2EE applications run in a controlled environment. It's a question of trust. I deal with web applications where I'd put more trust in the config of the environment than in the code itself - here that statement makes no sense. OTOH if I were writing an app to be run on desktop PCs then I'd be a bit suspicious of anything fetched from the local system.

I would....sanitize it


Validate inputs (i.e. accept or reject them in their entirety)

Sanitize outputs (convert them to a representation appropriate to the medium they are going into).

Sanitizing inputs is a really bad idea. You don't know where the data is going until your code looks at it. If it can arrive in your code in a state where it can do something unexpected (code injection, buffer overflow etc) then its too late to fix the problem.

  • This is great insight. @PwdRsch, thank you for commenting as well.
    – medokr
    Jun 30, 2014 at 18:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .