Jacques1

Are you storing the plaintext password when the log-in fails? PHP allows you to specify the type of a parameter in the method signature: <?php class LoginAttemptsLog { public function __construct(PDO $pdo) // note the "PDO" type declaration { } } // passing anything other than a PDO instance leads to an error $loginAttemptsLog = new LoginAttemptsLog(123); The benefits are that PHP can automatically validate the parameter types, you get a parameter documentation for free, and good IDEs can use the information to assist you and point out mistakes. In PHP 7, you can even have type declarations for scalar types (strings, integers etc.). As to the improvements: LoginAttemptsLog may be a better name Static values like the number 1 belong directly into the query; it doesn't make sense to pass them as parameters When you have multiple methods doing almost the same thing, create a private or protected method for the common code and call that in the public methods instead of literally duplicating the code. No. Unless you have reasons to believe that the timestamp returned by NOW() is not what you want.

Then enable exceptions for mysqli so that you get a proper error message whenever something goes wrong: <?php // make mysqli throw an exception whenever it encounters a problem $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; $database_connection = new mysqli(...);

While we're at it: Representing truth values with “y” and “n” is a bad idea. While this may make perfect sense for a human, it doesn't make any sense for the database system. From a technical perspective, it's just arbitrary text, so if a buggy application or confused human instead stores “yes”/“no” or “1”/“0” or “yea”/“nay”, this is accepted as well, and now it's no longer clear whether the value is true or false. Use the BOOLEAN type for an unambiguous representation of booleans.

Also test the page in different browsers. Styles or scripts created within JavaScript are not supposed to be covered by CSP, but there have been several bugs which broke that rule. If the code runs fine in one browser but not the other, this can indicate a browser bug.

How did you end up with this strange error format, anyway? There should be a detailed SQL error message explaining exactly what the problem is. Which database interface are you using? PDO? mysqli?

Yes. And all you have to do in this case is apply a CSS rule to an element with an ID. You've probably done this hundreds of times in your current CSS files.

The api.js violation is caused by not whitelisting the reCAPTCHA URL on https://www.gstatic.com. The flogin.php violation is caused by an inline style attribute. The jQuery violations are unclear without the code. Find your JavaScript code which uses the jQuery feature that triggers the violation. It also helps if you use the non-minified jQuery version for debugging.

The only way to answer the question is to actually measure the time and find the bottleneck. Run the query directly in the database prompt and check the exact time. The execution plan (EXPLAIN SELECT ...) tells you how the query is processed and whether it should be optimized. If that isn't the reason, there may be something wrong with the way you issue queries (e. g. nested loops with individual queries instead of joins). If that still isn't the problem, reduce the code until you've identified the part which is slow. Profilling also helps.

When the client makes a preflight OPTIONS request, you need to respond with Access-Control-Allow-Origin, Access-Control-Request-Method (only if you're using more than GET and POST) and Access-Control-Allow-Headers. When the client makes the actual request, you need to respond with Access-Control-Allow-Origin. Right now, it seems you allow CORS for absolute everything. That's a very bad idea, because the same-origin policy exists for a reason. You need to allow CORS for individual resources (hence the name). So if a particular PHP script should be accessible from other domains, that's when you enable CORS for this script. Probably the most natural approach is to set the headers within the script. If you insist on doing it with the webserver, you need to apply the headers on a per-resource basis. In any case, skipping script execution in case of an OPTIONS request is extremely confusing, so, no, I wouldn't do that.

What error? You've asked the browser for a report of CSP violations, and you've received a report of CSP violations. What's the problem?

And the $order_complete variable comes from where? You realize that variables only exist while the script is running, right? When the page is reloaded, the variables from the previous run are long dead. The overall approach seems very odd, so it might be a good idea to start from scratch: Braintree appearently uses POST requests to confirm orders. So you need a script which reacts specifically to POST requests (see $_SERVER['REQUEST_METHOD']), not plain GET requests. When you receive a (positive) confirmation, you send an e-mail. But don't use the strange approach of including some other script which then sends the e-mail. This is extremely confusing, and I bet that requesting the script directly in the browser causes trouble. If you don't want to have the e-mail code directly in the main script (which makes sense), define a function or method and then call it in the main script. After the confirmation has been processed, you redirect the client to a status page which merely displays the success/failure message. Since the status page doesn't do anything, the client can reload it as often as they want. See the PRG Pattern for a more detailed explanation.

If the script uses CORS, yes. But you still need the CORS headers in the response.

The header syntax is still wrong. You can't have whitespace between the header name and the colon. It's Content-Security-Policy-Report-Only: default-src 'self' https://www.google.com/ https://ajax.googleapis.com/; report-uri http://localhost/xampp/test/reportcspviolation.php ^^^^ no whitespace before the colon allowed, only after it

When you set custom HTTP headers, the client has to preflight to determine whether the actual request will be valid. This is the OPTIONS request you're seeing in the log. When you respond with a 401 code, the client assumes that the test has failed and will not send the actual request. To fix the problem, exclude OPTIONS requests from the header check so that the client will get a 200 response.

The syntax is broken, because you've just copied and pasted the attributes of the meta element. You need a valid HTTP header. A report-only policy also requires an extra script which processes the reports and is specified with the report-uri directive. Since you probably don't have such a script, reporting makes no sense. Content-Security-Policy: default-src 'none'

Don't hijack threads of other users.

CSP rules are defined with an actual HTTP header, not a meta element. You either make your webserver add the header, or you use the header() function in PHP.

It would help a lot if you told us what you want to do rather than how you think it should be done, because clearly your current approach is horribly misguided. So you want to react to mouse events. And then what? Do you understand that JavaScript can handle mouse events and communicate with the server through techniques like Ajax?

A huge problem of your current approach is that the entire data gets lost when the payment process doesn't go as planned (which can always happen). In case of a problem or a dispute, there isn't much you can do, because the session has probably been cleaned up already. Storing the “order” in the database and simply setting a flag is far more reliable. I'm not sure what you mean by “session injection”. The user cannot directly edit the session, unless there's a severe vulnerability in your application.

You don't, and why would you care? Bot traffic is the background noise of the Internet, and there's no reason to worry about it as long as the bots don't cause any harm. The only reason for making the registration less bot-friendly is to prevent malicious behavior like spamming. Otherwise it's completely irrelevant whether the request comes from a human or a bot.

... which doesn't mean it's right. The only argument for using the e-mail address is that it's slightly more convenient for the user. Security-wise, it's bad in every aspect and the reason why e-mail addresses keep getting leaked. If they were only used for sending e-mails, they could be stored separate from the web application. ECB mode. When the ciphertext only depends on the key, you can encrypt the plaintext and do arbitrary lookups in the database. But then again you're sacrificing security for convenience.

You should avoid both conditional scripts and animations which happen while the page is still loading. The cleanest solution is to simply use CSS classes to hide and display elements (e. g. class="invisible"). If you must have the animations, use data attributes to pass the session information from PHP to JavaScript. Then do the conditional animation within an external JavaScript file. Last but not least, there are workarounds for inline scripts: You can either use hashes or random nonces to whitelist individual scripts. However, this is complicated, not supported by all browsers and simply unclean.

Fix your syntax.

Probably. So, yes, this can in principle be used for bot detection. However, note that you'll also have false positives, i. e. legitimate users clicking on the link. For example, a visually impaired human may not realize that the link is hidden due to a bad user interface or a bad screenreader. That means you can't just reject the request. You still need a fallback for humans (e. g. a CAPTCHA). There's a lot you can do about bots: There are large blacklists of known spammers like StopForumSpam, Project Honey Pot or The Spamhaus Project. Invisible form fields that mustn't be filled out also work pretty well as a spam trap. Statistical spam filters are very effective against spam messages. CAPTCHAs are annoying, but they work. You can at least use them as a second line of defense when the user has already triggered some other bot detection mechanism. But again: None of this is perfect, so you should be very careful with hard bans.

Don't use the e-mail address as an identifier. Use an additional public username. Misusing e-mail addresses as usernames is generally a bad approach, because it's almost impossible to hide them even from the public interface. For example, if I want to check if foo@example.com is registered, I can simply measure the time (as the slow bcrypt check only takes place when the address exists).