What I was getting at - I hope for a future where the easy to do is the secure option, with programmers having to really go out of their way to do something dangerous.
09.08.2025 14:17 β π 1 π 0 π¬ 1 π 0@craigfrancis.bsky.social
Security, Accessibility, Performance... trying to make the world better.
What I was getting at - I hope for a future where the easy to do is the secure option, with programmers having to really go out of their way to do something dangerous.
09.08.2025 14:17 β π 1 π 0 π¬ 1 π 0Why is the last one the easiest to type, read, and dare I say it understand?
(not actually understand, if you did then you wouldnβt do this, but anyway).
Baby purple plant, itβs so cute.
Itβs starting to grow, and is in a new pot.
Itβs now a good size, providing a bit bit of colour while next to the window.
Ahh, itβs taken over, what happened; itβs taking up all of the space, and some more.
This is one of my baby plants :-)
12.06.2025 11:23 β π 1 π 0 π¬ 1 π 0With identifiers in SQL, this should either be a developer defined string in the SQL (e.g. have an allow-list array, where the key is an alias or numeric offset, the values are the SQL)β¦ or, your database abstraction should have a way to parameterise, e.g. $aliases in:
github.com/craigfrancis...
Yep, Iβve got some examples in PHP:
github.com/craigfrancis...
If memory serves, youβre using Go atm; so this is how I would start, with a package thatβs for the database abstraction (maybe taking an SQL string, or individual parameters for an ORM):
github.com/craigfrancis...
I would add that developers still make mistakes with prepared statements (especially when the SQL string is built via complex conditions/concatenation/etc, or junior developers make edits), so you must also validate the SQL strings are developer defined:
eiv.dev
Are you safe from injection vulnerabilities?
Even using abstraction layers like Doctrine or parameterised queries mistakes can still happen.
@craigfrancis.bsky.social shows us how mistakes can be made and what can be done to mitigate them.
Buy your ticket here: https://buff.ly/40Ck2WR
#phpuk
Agree completely, itβs why I see all automated pen test results as the first draftβ¦ they are just the start of an investigation, where results could be discounted immediately, or be part of a discussion with the developer. Also, no found βissuesβ does not mean the system is 100% secure.
20.01.2025 17:25 β π 0 π 0 π¬ 0 π 0I believe itβs to cover a user following a link to the API (maybe from an email, or malicious link), if the API can return HTML content, it would be like a normal web page for the browser; so pen test tools like to see a βnoneβ CSP.
20.01.2025 01:43 β π 0 π 0 π¬ 1 π 0Itβs how they got it to work, while they take a HTML string, a different package could take a CLI string in the same way.
So the functions first argument can be βconvert ? -resize ? ?β, and because itβs unexported, that must be provided during compile time.
And, to prevent completely, use Google Safe HTML package as an example, and use an βun-exported string typeβ.
e.g. define a package/function where the first argument is for the command string, the rest get escaped as arguments⦠partial example:
github.com/craigfrancis...
I think a lot of people know about it, but mistakes still happen, and as an industry we havenβt implemented anything that actually stops it (e.g. ORMs often have a complicated interface).
eiv.dev
XSS vulnerabilities keeping you up at night? π± Google's new "Commitment to Secure by Design" whitepaper has answers! Safe Coding and web platform improvements are key. Read more (page 7):
static.googleusercontent.com/media/public...
SQL Injection still exists despite abstractions like ORMs, QueryBuilders, & Parameterised Queries; simply because itβs easy to make mistakes (especially for new developers). Programming languages could find/stop these mistakes by identifying βtrusted developer defined stringsβ:
eiv.dev