Es difícil darle una respuesta detallada, ya que mucho dependerá del código real que utilice para implementar este proceso. Lo primero y posiblemente lo más importante a considerar es la validación de entrada Y salida en los datos suministrados por el usuario. Hay muchos buenos recursos sobre eso, enlace viene inmediatamente a la mente como el "ir a" para eso.
En cuanto a su enfoque actual, sugeriría que en lugar de tener ScriptA.php POST a ScriptA-verify.php, debería POST a ScriptA.php y manejar la verificación allí. Por todos los medios, logre esto haciendo una "inclusión" de ScriptA-verify.php, pero lo que esto significa es que no tiene la complejidad agregada y, por lo tanto, el riesgo de volver a enviar datos a ScriptA.php si ScriptA-verify.php devuelve problema. Los datos del formulario original estarán disponibles para usted a partir de sus variables saneadas derivadas de $ _POST (no use $ _POST directamente, consulte la validación de la escritura anterior).
El superglobal $ _SESSION es "bastante seguro" pero hay una publicación decente aquí que puede encontrar un poco más de: ¿Alterar una variable $ _SESSION en PHP a través de XSS? . También hay otros en Security StackExchange.
No tengo la sensación de que su cheque de $ _SESSION ['userid'] será particularmente a prueba de bombas, aunque mucho de eso dependerá de conocer otros detalles específicos del proceso que está desarrollando. Por ejemplo, la capacidad de secuestrar una sesión si la sesión se realiza a través de HTTP, no de HTTPS, las configuraciones de configuración de PHP en su servidor, etc.
Otra pregunta que me gustaría hacer es qué controles hay en las otras páginas que este inicio de sesión protegerá, de lo contrario, es potencialmente vulnerable a cosas como la Referencia Insegura de Objetos Directos. En resumen, no asumas que la gente siempre pasará por landing.php para ir a "secured-page1.php". Si no hay nada en secure-page1.php para garantizar una sesión válida, todos sus esfuerzos serán en vano.
Tampoco veo nada que proteja a sus usuarios del ataque CSRF. De nuevo, depende de lo que realmente haga la aplicación, pero si la única comprobación antes de cargar una página es para una sesión válida, entonces sería trivial forzar al navegador de un usuario a solicitar páginas específicas como restablecimientos de contraseña o similares. Nuevamente, el sitio OWASP puede ayudarlo aquí.
Esto es una especie de prueba rápida, respuesta de volcado de cerebro. Si puede proporcionar detalles más específicos del código detrás de su aplicación y posiblemente su nivel de experiencia, es posible que le brinde un nivel más bajo y un asesoramiento más completo.