What security features would you find useful or expect from a PHP framework? I have a PHP framework that I've developed that I'm going to be releasing as an open source project, but I want to make sure that it has appropriate security features. Here is what I have so far:

  • ACL-support
  • Prepared statements/parameterized queries
  • CSRF protectection
  • XSS protection
  • Database-based sessions
  • Form validation/filtering

What else should a PHP framework reasonably include?

  • 1
    How are you doing XSS protection? I'm working on implementing safetemplates for a variety of web templating languages but have yet to really look into the PHP space. I'd be happy to advise if that approach looks like a good fit for your work. Sep 13, 2011 at 1:59
  • Hi Mike. At this point, the XSS protection is just done via automatically filtering form input, but after looking at your paper, other possibilities seem worth exploring as well. If you'd like, send me an email. I'd love to talk further. Sep 13, 2011 at 4:36
  • 2
    Filtering of input is dangerous, you don't know where and how input will be used. It might be further encoded/decoded whatever. The proper way to prevent injection attacks is by output escaping imho (for xss as well as sqli),
    – chris
    Sep 13, 2011 at 5:27
  • @Chris - You bring up a valid point. I think perhaps I'll disable it by default, but allow developers the option to add filters as needed. I haven't given too much to output escaping as the framework doesn't have a built-in template system, but yours and Mike's comments are causing me to rethink that somewhat. Sep 13, 2011 at 6:17
  • 1
    @chris not sure I'd say that filtering input is always dangerous.. White-list filtering can be an effective method of reducing input validation issues. eg if I know a field should only contain numeric characters and be of a certain length, validating it to ensure that's the case seems like a good plan, and having the framework provide facilities for that is (imo) useful... Sep 13, 2011 at 22:03

4 Answers 4


Well, building security into a framework is not an easy task. Take for example XSS protection you mentioned. Current trend in Web Application security states that three things are required for dealing with injection-flaws:

Even when handling all the above server-side, you could still be vulnerable to DOM XSS attack when vulnerable Javascript code has been introduced to the application (and, for example, jQuery might introduce DOM XSS as well).

Personally, I think the most important, and often neglected features of the frameworks are secure defaults and secure code examples. Developers often copy&paste the code or leave settings as default. So if you're introducing tokens as a CSRF protection, add them to every form by default and allow that to be toggled off in code/config.

If you're looking for some kind of a checklist for secure frameworks, there once was an OWASP project (now closed) - Web Application Security Manifesto. It aimed to provide such a testing and is currently the best checklist there is. Also browse through various OWASP cheat sheets to help you with implementing each security controls.

  • +1 for secure defaults and code examples, as well as the links. Looks like I have some reading to do. Sep 17, 2011 at 9:28

I'd recommend adding anti-automation measures to it. A user of the framework could choose what pages he wants to protect with this feature (for instance a login page or a feedback form). If an attacker would submit the form multiple times, he would be faced with a CAPTCHA for each subsequent request, based on his IP (not session ID!).

Furthermore, session handling is a tedious task. The framework should make sure that:

User-generated sessions are not accepted This in order to prevent session hijacking, where an attacker generates a session ID for someone else to use

Session IDs are re-generated after authentication So that when an attacker succeeds in convincing a victim to use a certain session ID, the attacker will not have an authenticated session when the victim logs in

Session IDs of authenticated sessions are never transmitted over HTTP But use SSL for all authenticated stuff

Session cookies have the proper flags HttpOnly, and Secure flag for authenticated sessions

Furthermore, I'd recommend that the framework allow the developer to set caching policies. For pages that are served to authenticated users, which might contain privacy sensitive data, caching should be easy (or even default) to turn off.

  • The issue with "CAPTCHA for each subsequent request based on IP" is some organisations/colleges/universities/etc share the same public IP. There you risk presenting a CAPTCHA for users on their first visit/hit due to previous hits from users with the shared IP. I suppose like most framework requirements, a lot depends on the scenario you are catering for.
    – James
    Nov 14, 2014 at 18:21

Oh joy - another PHP framework. Please excuse my sarcasm, but there are a huge number of frameworks already floating around in the wild. Most are bloated, slow and full of security bugs. But at least you are trying to address security problems up front.

I'd say it's questionable whether a framework should provide it's own database abstraction layer. e.g. Sometimes the active record pattern is useful, but not always.

By far the most valuable security add-on would be guarantees of backward compatability to encourage your user base to upgrade when you release new versions.

As per my comment elsewhere, validation is not a security issue - correct representations of data is. Providing a simple mechanism for changing between representations for different targets and to/from destination neutral formats (which usually means some tweaks to base64 encoding) would be good.

However validation for functional issues is not a bad thing - e.g. making sure that a departure date for a booking is after the arrival date.

Logging is very important.

Sandboxing of file I/O would be worth considering.

As Chris says - you should provide prevention against session hijacking/fixation.

You might consider providing an authentication framework (after all if you've got ACLs you're already imposing some constraints on how authentication is implemented).

If you want a really secure framework then think about how you'd implement non-searchable sessions (the only solutions I've come up with for this rely on daemons for privilege separation - so are entirely unsuitable for most people who would want to secure session data - i.e. those on cheap shared hosting packages).

There's lots of other stuff outwith the security domain - e.g. asynchronous messaging support. But bear in mind every time you add more functionality you may be denying the ability to use a complementary framework alongside your own (e.g. smarty, seagull, doctrine are all very capable in specific areas)

  • I understand the skepticism and usually get a similar response whenever I ask a question about a PHP framework. I guess it's par for the course. Still, if most are bloated, slow, and insecure, doesn't that mean there is room for something that isn't? I wrote the framework for my own purposes, but decided to open source it as well as I feel there are specific problems that it can solve differently than other frameworks. My goal with it is: Simple, Stable, Secure. +1 for your suggestions. Thanks. Sep 13, 2011 at 20:37

Input validation rules engine. (and output for that matter)

  • +1 - Thanks, the framework includes that, but I forgot to list it. Sep 12, 2011 at 23:06
  • I disagree: You should rarely validate input for security reasons - you should always use an appropriate representation for your data depending on where it is going (e.g. mysql_real_escape_string, htmlentities etc). By rejecting input you provide a mechanism for an attacker to identify gaps in your blacklisting.
    – symcbean
    Sep 13, 2011 at 15:21
  • 1
    Interesting take on it. I was talking more about building in a framework that allows for whitelisting. For example, I know that my phone number should look like xxx thus, test for that.
    – CtrlDot
    Sep 13, 2011 at 16:12
  • 2
    @symcbean I know where you're coming from in saying that the "sink" for a given piece of data is important in deciding what defensive mechanism to use, but I must say I disagree that input validation shouldn't be used for security purposes. I would say that in many cases white-list input validation is a good first line of defence against issues such as XSS or SQLi (not to say you shouldn't also encode output returned to the browser, or not use paramterized stored queries for database access) Sep 13, 2011 at 22:06

You must log in to answer this question.

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